-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Move constraints generation to separate job in CI workflow #34990
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
Move constraints generation to separate job in CI workflow #34990
Conversation
|
This one should prevent the case we had few days ago - which prevented tests from running few days ago (workarounded by #34918). After new providers have been released today by @eladkal, PyPI constraints generation has a chance to succeed today - the "preview-constraints" job in this PR will be green if it does, then i will also restore the actual constraints generation in the final step. |
ed8282f to
c158122
Compare
amoghrajesh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM +1
|
Yes. It looks like releasing the new providers unblocked |
8f8a9b6 to
f35c9b3
Compare
Well. Not really - I need to look further :( |
49c8cda to
25b7ad6
Compare
We generate constraints for preview right after images are build, in order to be able to see the output and to diagnose which dependencies have been updated later in the process. So far we were doing it in CI workflow and When constraints generation failed however (for example because pip backtracking takes a log ot time), it faied build image workflow and did not allow tests to complete. This PR extracts constraint generation to CI separate job which does not block tests from running in case constraints generation fails or times out. It also moves out the steps from the composite action which allows to better see which step failed and allows to see the constraints used in each job more easily.
25b7ad6 to
d68f6cb
Compare
|
Seems I got it fixed. For whatever reason Not obvious at all, but at least the outputs we get when similart things happen in the future should be more readable and it should not block the PRs. |
The PROD image uses source constraints to get built. The apache#34990 had moved the constraint generation to CI workflow which works for main builds, but for regular PRs we also need to upload them in the build-image workflow - otherwise PROD image build cannot find them as artifacts. This PR restores only source constraints upload as artifacts (this is very fast)
…#35004) The PROD image uses source constraints to get built. The apache#34990 had moved the constraint generation to CI workflow which works for main builds, but for regular PRs we also need to upload them in the build-image workflow - otherwise PROD image build cannot find them as artifacts. This PR restores only source constraints upload as artifacts (this is very fast)
We generate constraints for preview right after images are build, in order to be able to see the output and to diagnose which dependencies have been updated later in the process. So far we were doing it in CI workflow and When constraints generation failed however (for example because pip backtracking takes a log ot time), it faied build image workflow and did not allow tests to complete. This PR extracts constraint generation to CI separate job which does not block tests from running in case constraints generation fails or times out. It also moves out the steps from the composite action which allows to better see which step failed and allows to see the constraints used in each job more easily. (cherry picked from commit a450b81)
The PROD image uses source constraints to get built. The #34990 had moved the constraint generation to CI workflow which works for main builds, but for regular PRs we also need to upload them in the build-image workflow - otherwise PROD image build cannot find them as artifacts. This PR restores only source constraints upload as artifacts (this is very fast) (cherry picked from commit 40b9d2b)
We generate constraints for preview right after images are build, in order to be able to see the output and to diagnose which dependencies have been updated later in the process.
So far we were doing it in CI workflow and When constraints generation failed however (for example because pip backtracking takes a log ot time), it faied build image workflow and did not allow tests to complete.
This PR extracts constraint generation to CI separate job which does not block tests from running in case constraints generation fails or times out.
It also moves out the steps from the composite action which allows to better see which step failed and allows to see the constraints used in each job more easily.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.