-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Migrating issue generation to breeze release-management #38062
Conversation
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.
NAAAJS.. Few comments:
- we should remove the
dev/*
script in the same PR
We should run the command in CI together right after Airflow Release And Helm Release commands - this way we will be sure that the command works (at least it will not break in the CI).
We already do that in case of providers:
- name: "Test providers issue generation automatically"
run: >
breeze release-management generate-issue-content-providers
--only-available-in-dist --disable-progress
In the prepare-test-provider-packages-wheel
job.
For Helm it should be added in tests-helm-release
jon
For Airlfow it should be added prepare-test-provider-packages-wheel
as this is where we also prepare airflow
package
- name: "Prepare airflow package: wheel"
run: breeze release-management prepare-airflow-package --version-suffix-for-pypi dev0
This is the main benefit of having the commands nicely packaged as breeze
commands - because we can run them in CI and we can be reasonably sure they continue working.
Also I guess there will be a follow up PR where we - possibly - do some refactor and extract the common parts of generate_issue_content_*
methods ? It looks like there are quite a lot of duplicated lines of code that could by DRY-ed (but I believe it shoudl be a follow-up PR once we get one or two rounds of releases and this will be proven to work - we might avoid some unnecessary coupling issues this way.
(also having it running in CI is ultimate proof that it works - and there is no need for the reviewer to run it locally - they will simply be able to see it in the CI :) |
Understood. Will make the changes for this |
Yeah I wanted to, but wasn't sure whether to keep this in case it doesn't work. |
Of course, I will be refactoring in a follow up. I know its messy :) |
It will get longer and longer over time. Ideally, we should do the same what the release manager does - i.e use latest version. It's rather easy for airflow - you could potentiallly add support for response = requests.get("https://pypi.org/pypi/apache-airflow/json")
response.raise_for_status()
latest_released_version = response.json()["info"]["version"] For Helm chart it shoud also be somewhat easy to get latest version ? I leave that exercise to you |
Ok understood, I can take it up in a follow up once this is stabilised. Your call, let me know |
Sure. Can be done separately :) |
Helm one has content right? You mean airflow one? |
@potiuk requesting small guidance here. I am hardcoding the versions as helm-chart/0.0.0 and helm-chart/0.0.0dev0 which is being tagged by previous stages in the workflow, not sure why it fails. Can i get some help here? ` 2024-03-14T11:35:48.9417362Z ##[group]Run breeze release-management generate-issue-content-helm-chart --previous-release helm-chart/0.0.0 --current-release helm-chart/0.0.0dev0 ` |
I don't think tagging is done? I could not find it actually ? Where is it tagged? I believe the previous steps only use existing tags but never tag it ? Or maybe I missed it ? |
Maybe I am slightly mistaken here but I was checking the process logs.
And in this breeze command the following happens
So I think it has a tag now. I will check out what the right one is |
@potiuk I ran a |
The job has passed now: https://github.com/apache/airflow/actions/runs/8292193216/job/22693362907?pr=38062 If all is ok, we can send this one in and I will pick up the follow ups asap. |
@potiuk can you take a round at this once you have some time? Just rebased onto the new HEAD of main :) |
Offline chat with @eladkal revealed that there is an inconsistency between how issues are generated for providers, helm-charts, and airflow. Initially I had fixed #37891 and realised that a bigger effort is needed to move everything to breeze. This PR moves issue generation from prepare_release_issue.py to breeze release-management and introduces two new commands.
The usage looks like this:
Tested for helm chart as well as airflow core.
Example output:
^ 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.rst
or{issue_number}.significant.rst
, in newsfragments.