Skip to content

Sync v2-9-stable with v2-9-test to release 2.9.0#38754

Merged
ephraimbuddy merged 17 commits intov2-9-stablefrom
v2-9-test
Apr 4, 2024
Merged

Sync v2-9-stable with v2-9-test to release 2.9.0#38754
ephraimbuddy merged 17 commits intov2-9-stablefrom
v2-9-test

Conversation

@ephraimbuddy
Copy link
Contributor

Time for 2.9.0rc2!

potiuk and others added 17 commits April 3, 2024 11:06
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)
A follow up after #38749 - we should also disable UV for cache
building in release branches. PROD images are building just fine,
but cache building for 3.11 fails for the same reason and we also
have to disable UV for the cache build.

(cherry picked from commit 370998d)
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)
@boring-cyborg boring-cyborg bot added area:API Airflow's REST/HTTP API area:dev-tools area:production-image Production image improvements and fixes area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues labels Apr 4, 2024
@ephraimbuddy ephraimbuddy merged commit 920921e into v2-9-stable Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:API Airflow's REST/HTTP API area:dev-tools area:production-image Production image improvements and fixes area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants