-
Notifications
You must be signed in to change notification settings - Fork 36
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
Include numbered version for release candidates #458
base: main
Are you sure you want to change the base?
Conversation
This change relies on having the github workflow fetch all tags, not just the branch that it is building. I assumed this is the case. |
According to https://github.com/actions/checkout it does not checkout the tags. |
We do not tag the versions in git. We also can't make multiple different versions for the same day. With this change the release candidates will have a version of the form 3.2.0rc20250205.0 3.2.0rc20250205.1 ... instead of just 3.2.0rc20250205. Signed-off-by: Boian Petkantchin <[email protected]>
5af50fe
to
fce5cbd
Compare
I changed it to fetch the tags. |
.github/workflows/build_packages.yml
Outdated
@@ -36,9 +38,14 @@ jobs: | |||
|
|||
- name: Build iree-turbine release candidate | |||
run: | | |||
./build_tools/compute_local_version.py -rc --write-json | |||
version_name="$(./build_tools/compute_local_version.py -rc --write-json)" |
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.
Did you test this (on your fork)? Variables set like this are not persisted between workflow steps automatically.
See
- https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable
- https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-output-parameter
version_name="$(./build_tools/compute_local_version.py -rc --write-json)" | |
version_name="$(./build_tools/compute_local_version.py -rc --write-json)" | |
echo "version_name=${version_name}" >> "$GITHUB_ENV" |
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.
You are right.
I removed the tagging.
build_tools/compute_local_version.py
Outdated
def get_next_available_tag(tag_prefix: str) -> str: | ||
""" | ||
Get the next numbered tag that does not exists. | ||
E.g. iree-turbine-3.1.0rc20250205. -> iree-turbine-3.1.0rc20250205.3 | ||
""" | ||
tags = ( | ||
subprocess.check_output(["git", "tag", "--list", f"{tag_prefix}*"]) | ||
.decode() | ||
.strip() | ||
.splitlines() | ||
) |
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.
I'm conflicted about pushing a tag for each nightly release. We do that in iree-org/iree, but it generates a lot of tags.
You could instead use the workflow run number, as we used to do there: https://github.com/iree-org/iree/blob/92ac1b2deea48c018ecb1f66a05d454b099ae294/.github/workflows/schedule_candidate_release.yml#L39-L44
A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.
WDYT?
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.
I removed the git tagging. If someone is interested in the exact commit they could go and retrieve it manually from the workflow.
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.
I made it include the github.run_number
in the version.
@@ -36,9 +38,14 @@ jobs: | |||
|
|||
- name: Build iree-turbine release candidate |
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.
We also can't make multiple different versions for the same day.
Yep. I thought about making a change like this one but figured that nightly releases are "best effort" anyways, and overwriting a nightly release if we want to pick up some commits before the next day isn't a major issue. I'm not opposed to adding a number suffix and allowing multiple releases per day, if you put the work in to make that possible. It's just more code to write and maintain.
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.
I wanted this to improve reproducibility as we are using pinned versions for the projects that depend on IREE Turbine.
Signed-off-by: Boian Petkantchin <[email protected]>
We can't make multiple different versions for the same day.
With this change the release candidates will have a version of the form
3.2.0rc20250205.0
3.2.0rc20250205.1
...
instead of just
3.2.0rc20250205