-
Notifications
You must be signed in to change notification settings - Fork 101
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
upload assets on tag #6318
upload assets on tag #6318
Conversation
Immediate thoughts:
|
|
One thing to keep in mind that I went through with https://github.com/zarr-developers/zarr-logo/pull/2/commits is that on download things get automatically zipped. Also: I can highly recommend experimenting with the |
Another component which I forgot to mention in my previous comment is our Ansible deployment stack especially Something to think about is the breaking impact on deployment if a new library/role release or new scripts are required to upgrade a server. I don't consider it to be a blocker per se but it might lead us to a dedicated upgrade documentation page similar to what we did for the Python3 migration. |
Reactivate that work
|
Add |
cf. #6318 (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.
Given the OMERO.server 5.6.5 experience, I am definitely in favor of inverting the release workflow i.e. migrate the artifact generation to GitHub Actions and mirror these artifacts under downloads.openmicroscopy.org.
A few inline comments and a couple of questions:
- the new process seems to fully drop the build suffix. Is that on purpose and do we know whether this might cause impact downstream?
- we might need to review whether this GH based process might affect a security workflow
I can't get a build number as bXXXX is internal to our CI. The build is now happening in GHA. |
I assume in the GitHub context |
Using the job id is an option |
https://github.com/jburel/openmicroscopy/releases/tag/v5.6.5-m3 using the run_id in the name |
Looking closely, I don't think the build number needs to be kept. the usage of get_latest_runs will need to be reviewed. This is mainly (only!) used to retrieve a latest run from Jenkins latest. |
Looking at another part, candidate for automation, not including the build number will allow to create the url by finding the latest release tag from the GitHub API . Including the build number will not permit that. |
.github/workflows/release.yml
Outdated
run: | | ||
set -x | ||
assets=() | ||
touch SHASUMS |
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.
How does the MD5 file that's in your tag get created? Do we need both?
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.
@sbesson and I discussed it and decided to remove the MD5
|
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.
One outstanding question about simplifying the for loop.
On the build number suffix, my understanding is that the impact is rather about cleaning up various locations and I am in favor of dropping it.
It partly raises the question of how a rebuild should be handled using GitHub Actions. I assume pushing a new tag?
For the build number, it will be matter of adjusting a few places. If we agree, I will roll back and do not add the build number |
Last 2 commits
Tested via https://github.com/jburel/openmicroscopy/releases/tag/5.6.5-m5 |
Any more comments on this PR? |
Is the missing leading |
oh. Let me check. That should not be the case. Edit: This is because I did not tag with |
The last commit has been tested using 2 tags. One starting with |
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.
Ready to test in the upcoming server release from my perspective
Follow up from 5.6.4 release.
This PR adds steps to the build workflow to avoid the manual migration of the artifacts from downloads.o.org to GitHub.
The workflow does the following, When a tag is pushed:
I have opted for one single
SHASUMS
andMD5
collecting the various values to simplify the selection and reduce the number of uploaded files.This can replaced the "release" job on CI
See https://github.com/jburel/openmicroscopy/releases/tag/v5.6.4-m1