Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add BranchPythonVirtualenvOperator #3

Conversation

jscheffl
Copy link

This PR is a split of the PR apache#33017 to add BranchPythonVirtualenvOperator.

As it builds on top of the other branch it needs to be merged behind, else it will not work - but pytests are needed.

Therefore before merging, the target repo need to be switched to apache/airflow:main.

FYI @AutomationDev85 @clellmann @wolfdn

@jscheffl jscheffl force-pushed the feature/add-branch-venv-operator branch 2 times, most recently from 9941e5d to 4e66370 Compare August 12, 2023 18:40
Owen-CH-Leung and others added 27 commits August 26, 2023 18:01
Put a quote to the entire curl command
Redis 5 relased last week breaks celery, celery is limiting it for
now and will resolve it later, we should similarly limit redis on
our side to limit redis for users who will not upgrade to celery
that will be released shortly.

Fixes: apache#33744
Only run it when the map may have changed (migration or core version
change), and also only check migration files (ignore things like
pycache).
There were still some left-overs of EAGER_UPGRADE in PROD image
building. Howwever "eager upgrade" only makes sense for CI images.
PROD images when being built should use eager upgrades as they
are produced in the CI image step.

This PR does the following:

* removes eager upgrade parameters from PROD image
* instead, prod image build has a new flag for installing
  the images: --use-constraints-for-context-packages which will
  automatically use constraints from "docker-context-files" if
  they are present there.
* modifies the CI workflows to upload constraints as artifacts
  and download them for PROD image build when "eager upgrade"
  has been used and directs it to use "source" constraints
* adds back support to "upgrade to newer dependencies" label
  that makes it easy to test "eager upgrade"

As the result, when PROD image is build in CI:

* when regular PR is run, it will use latest github "source" constraints
* whwn "eager upgrade" PR is run, it will use the eager-upgrade
  constraints that were generated during CI build
…che#33790)

The apache#33626 change missed an edge case where back reference new
link was in the top-level folder and crashed with ValueError.

Unfortunately back-reference command is one that we do not run (yet)
in CI to verify if it works, because we need a checked-out airflow-site
for it, so such errors might go unnoticed. However this error is an
indication that we likely should add it to CI - in order to avoid
situation when the command is expected to be working at release
time.
)

* Run back-reference breeze command as part of our CI builds

The `back-reference` command post-processes our docuementation to
add redirections for new pages in the old documentation, so that
user browsing the page can change version without hittin 404 error.

This command was not run in CI and some refactorings could break
it (as it already happened in apache#33626 - fixed by apache#33790).

Most other breeze commands are already run in CI, so this one should
be no different.

This PR adds back-reference generation as part of our regular
documentation building step.
* Vastly speed up provider documentation publishing

Publishing documentation is quite slow when preparing multiple
provider documentation - and this is mostly because we are serializing
copying of directories and checking if the directories are present.
Hhowever we can easily speed it up by parallelising the publishing
per-package.

This will speed up both CI and release-manager's docs publishing
step (vastly).

Co-authored-by: Elad Kalif <45845474+eladkal@users.noreply.github.com>
When we are building PROD image in CI for non main branch, we are
installing providers from PyPI rather than building them locally
from sources. Therefore we should use `PyPI` constraints for
such builds not the "source" constraints (they might differ).

This PR adds two steps:

* In the CI build, when we do not build providers we generate
  PyPI constraints additionally to source constraints
* In the PROD build we use the PyPI constraints in case we
  do not build providers locally
…che#33741)

As the name suggests, this test should verify that a task is not adopted if it belongs to a DAG which is not in RUNNING state.

Before this change: the test setup creates a DAG in RUNNING state, but the test passes because the task has queued_by_job_id set to a live scheduler (so is not adoptable for a different reason - it's not an orphan). It looks l
ike it was a copy-paste from the previous test case (test_reset_orphaned_tasks_no_orphans) which is supposed to test this scenario.

After this change: the test setup is aligned with the test name - the task is an orphan but its DAG is not running so the task cannot be adopted.

Co-authored-by: daniel.dylag <danieldylag1990@gmail.com>
* Chart: Update postgres subchart

* Move newsfragment
darkag and others added 26 commits September 6, 2023 23:09
* Custom fetch all handler for vertica to not miss errors

* missing parameter

* Fix test (set nextset to none)

* fix static checks

* fix static-check error

* fix static-check error

* rename variable

* add docstring

* fix docstring
The tests for Salescforce hooh were too strict - they were
expecting a specific version and when new salesforce-simple library
has been released (1.12.5), the version changed - the tests
started to fail.

This PR fixes the tests by accepting any version.
…pache#34119)

The elasticsearch handler got all configuraiton parameters
from the "elasticsearch_config" section but it means that in
airflow versions pre 2.7 it could get old config keys which renders
the new provider unusable.

This PR filters out configuration parameter to only pass valid
parameters for the new handler.

Fixes: apache#34099
…eline_task (apache#32903)


---------

Co-authored-by: Adam Best <abest@adams-mbp.lan>
Co-authored-by: Adam Best <>
Co-authored-by: Adam Best <unknown>
Co-authored-by: Hussein Awala <hussein@awala.fr>
* allow empty access control on dags

* Add test which demonstrates loss of information during ser/de

* Keep empty value when serializing access_control dict
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
The docstring in the class UndeployModelOperator regarding the endpoint_id is not correct. This parameter accept only the id of the endpoint and not the path as written 'projects/{project}/locations/{location}/endpoints/{endpoint}'
Signed-off-by: Jakub Dardzinski <kuba0221@gmail.com>
The query param `tab` is set on the DAGs view when any of the tabs _within_ the details panel is selected, thus we should show the details panel, even if the user previously hid it.

There are 2 main scenarios where a user would navigate to such a link:
1. User clicks on one of the pills on the DAG view (Graph, Gantt, Code). Imo, the user will expect to see the relevant tab in the details panel, even if they have it hidden.
2. User clicks on a link (e.g. from DAG runs, or someone sharing a link). Less clear cut than scenario 1, but still I think the most user friendly result is to show the requested tab (in the details panel).
)

We should only tag :latest image when default image is used because
this step always tags `apache/airflow:X.Y.Z` (defaulti Python) to become
the `apache/airflow:latest`. This step was previously run for all Python
versions which could have two effects:

* if non-default image completed before the default such tagging
  would fail as the `apache/airflow:X.Y.Z` was not ready yet to
  be used as target of `apache/airflow:latesti` tag

* if non-default image completed later, it would be no-op because
  the `apache/airflow:latest` already pointed to `apache/airflow:X.Y.Z`
* Update RELEASE_NOTES.rst

(cherry picked from commit 891fae5)

* fixup! Update RELEASE_NOTES.rst

(cherry picked from commit b8c4166)

* Apache Airflow 2.7.1 has been released
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the Stale label Oct 24, 2023
@jscheffl jscheffl closed this Oct 24, 2023
@jscheffl jscheffl deleted the feature/add-branch-venv-operator branch October 28, 2023 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet