Sync v2-9-stable with v2-9-test to release 2.9.0#38754
Merged
ephraimbuddy merged 17 commits intov2-9-stablefrom Apr 4, 2024
Merged
Sync v2-9-stable with v2-9-test to release 2.9.0#38754ephraimbuddy merged 17 commits intov2-9-stablefrom
ephraimbuddy merged 17 commits intov2-9-stablefrom
Conversation
We already had to do this very sensitive part of the workflow in three places, so it makes sense to extract it to a composite action. This means that we need to do one more checkout from the target branch first (otherwise the action would not be available) but we avoid code duplication and fragility this way. (cherry picked from commit 76c92c3)
…38703) When Airflow installs a pre-release provider version we can add the `>=x.y.zdev0` or `>=x.y.zrc1` to pre-release provider specification. This is necessary to install dev0 or rc* packages when we release them for testing, when the pre-installed provider is a "chicken-egg" provider that does not yet have an "official" version - because otherwise the dependency would not allow the provider to be installed. However, the "final" package should have just `>=x.y.z` without the pre-release specification, because by the time we release the final version, the pre-release provider package should be already released. This PR implements such pre-release stripping. In cse we prepare the "final" version of the airflow package, all the preinstalled provider's specifications got the `>=version` stripped off all the prerelease information. The `>=1.2.0dev0` or `>=1.2.0rc1` is for example turned into `>=`1.2.0`. Co-authored-by: Andrey Anshin <Andrey.Anshin@taragol.is> (cherry picked from commit 1759336)
Few small changes after checking the tag-providers command: * removed capturing output when pushing tags - this way we see what we pushed * removed command variables * better array concatenation with unpacking * removed shlex.quote (cherry picked from commit 0c07142)
For production build we should apply the package prefix depending on branch we are in. In main we apply dev0 suffix for development, but in the release branch we should not apply the suffix. (cherry picked from commit 0f7f2fa)
(cherry picked from commit 6c217ae)
…38739) The UV_REQUEST_TIMEOUT was only briefly the correct parameter name, (UV 1.6.0). It is still working as a fallback, but the right parameter name is UV_HTTP_TIMEOUT. This PR renames the flag and build args/env variables appropriately - and also fixes a few annoyances connected with this parameter: * it was not possible to specify --use-uv/uv-timout for `breeze` `breeze shell` and `breeze start-airflow` commands which could resut in rebuilding the image and you had to rebuild image manually with `ci-image build` if you wanted to change uv/no-uv * the ARG was not properly passed in PROD image and resulted in empty string set as UV_REQUEST_TIMEOUT which resulted with a warning printed by UV and falling back to default 300 * we have now global constant for default timeout (cherry picked from commit 329c76d)
* Make UV_HTTP_TIMEOUT default value bigger in WSL2 environment When uv docker build is run in WSL2 the default timeout does not cope well with downloading big packages and times-out with the default UV timeout. This PR performs detection of whether you are in a WSL environment and changes the timeout in case you are in WSL2. It also raises error when WSL1 is detected (not supported by Breeze at all). In case the WSL1 detection is wrong we also have an escape hatch by manually specifying `--uv-http-timeout`. * Update dev/breeze/src/airflow_breeze/utils/platforms.py Co-authored-by: Andrey Anshin <Andrey.Anshin@taragol.is> --------- Co-authored-by: Andrey Anshin <Andrey.Anshin@taragol.is> (cherry picked from commit fb7f82c)
The instructions on what to do was hidden in a folded group and we need to make sure it is printed straight in the output. Also we should not print the nasty traceback, as it is not very useul, the failing python command already prints appropriate error/informational messages and there is no need to clutter the output with the traceback when the command fails. (cherry picked from commit 6172b44)
…8749) In main we are using `uv` to build CI and PROD images to gain enormous speed improvements. This helps with faster PR checks and iterations and lowers the CI cost. However `uv` is not entirely stable yet and there are conditions that make it fail sometimes (for example when old packages, not excluded by our limits are published with wrong versions), also release imge is built with `pip` and will continue to be built with `pip`. The gains for PROD iumage builds with uv are much smaller than the ones for CI builds, so it's perfectly fine to switch all `release branch` builds to use `pip` for PROD image builds - we do not loose too much by doing it, but we gain stability. (cherry picked from commit be89300)
Re-order the Tags in our API Spec view to be sorted alphabetically. This one is quick PR to fix the current order, but perhaps we could work on adding a pre-commit to ensure this list stays sorted. (cherry picked from commit 9b2d7cb)
(cherry picked from commit 5337066)
--------- Co-authored-by: Collin McNulty <collin.mcnulty@gmail.com> Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com> (cherry picked from commit 02ce3a0)
* Fix decryption of trigger kwargs when downgrading. This failed because the query for Triggers after the downgrade lazy loads the taskinstance table(ORM) which doesn't have the task_display_name column at that downloaded point. The fix was to query specifically on the encrypted_kwargs column. * Properly positon the decryption after downgrade and not in offline migration (cherry picked from commit 567246f)
jedcunningham
approved these changes
Apr 4, 2024
potiuk
approved these changes
Apr 4, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Time for
2.9.0rc2!