possible release workflow enhancements
It would be nice if
[JENKINS] Release could take an optional parameter, e.g.
strip-suffix that would have the same function as the "Release" checkbox on http://jenkins.gromacs.org/job/Release_workflow_master/build?delay=0sec ie strip the "-dev" string suffix from the versions. The default behaviour should stay as it is, so it's hard to make a tarball that could be mistaken for the real thing (unless someone intended that it might become the real thing).
Even more ambitious, a related workflow build could take the regressiontests, compute the md5sum, and make a commit on the source repo as a child of the given refspec. That commit would update the hash against which the future download would be compared. Some human will still have to go and edit the resulting commit message and choose what versions to bump, unless we want to get fancy and make inferences based on how well the most recent tag on the branch matches the current branch name.
#1 Updated by Teemu Murtola about 4 years ago
- Project changed from GROMACS to Support Platforms
- Category set to Jenkins
Related to organization of the builds, what value (if any) you see in the build history in Jenkins for the different builds related to this? Could we have just one set of builds, common for all branches?
Currently, the separate packaging builds exist mainly to optimization purposes to 1) reduce storage requirements for the build artifacts, since there will be fewer duplicates, and 2) reduce the time it takes to run the workflow if the code/tests haven't changed.
A branch-agnostic build could still take advantage of these, as long as it is triggered only from one branch within a certain period of time.
#2 Updated by Mark Abraham almost 4 years ago
Darn, I lost my longer answer in a reboot :-(
Yes, I think we can have one set of builds. In practice, we don't need to be able to do releases from more than one branch at the same time.
I have scripts that automate combining the release notes (currently local RST, sphinxed) with the workflow artefacts to put them on the website. We could also expand the scope of the release workflows to also build the release notes (e.g. updated into final form in the version-bump patch)