[FAST_BUILD] Introduce fast build

[mathbunnyru]

Describe your changes

Issue ticket if applicable

Checklist (especially for first-time contributors)

• I have performed a self-review of my code
• If it is a core feature, I have added thorough tests
• I will try not to use force-push to make the review process easier for reviewers
• I have updated the documentation for significant changes

[mathbunnyru]

This approach allows us to test the most crucial changes in the CI in a fast way.
We need to build 2 images because we really want to check the upload/download part because it might be broken as well.

As I'm not sure this is the best approach, and it adds some noise to the CI graph and the workflow file is bigger, I would like to hear some ideas, maybe there is a better approach.

[mathbunnyru]

If it's a PR, then everything depends on whether the PR title has a [FAST_BUILD] substring.
During the push to the main branch a github.event.pull_request.title property is empty (I hope), so we will always run the full build (which totally makes sense).

[mathbunnyru]

I don't understand what's going on 😢

[mathbunnyru]

Finally got it working. Today I learned GitHub env variables are strings, not some kind of GitHub magic, so, the "false" string evaluates to true (if then later used as a condition).

What's cool (I suppose it's secure enough, but who knows), is that GitHub evaluates the expression after replacing env variables with values.
https://github.com/jupyter/docker-stacks/actions/runs/6712091950/job/18241119289

[mathbunnyru]

@yuvipanda you might find this feature useful - it allows to significantly reduce build time in PRs.
You need to add [FAST_BUILD] to the PR name and then only 2 root images will be built (and tested).
I think most of CI/infrastructure/start-script PRs will benefit from this change (and I wish I had thought of this feature a few years ago).

Please, review, if you have some time 🙂

[mathbunnyru]

I am merging this. I want to introduce new tests for run-hooks before we merge #2007.