Project

General

Profile

Feature #2066

possible release workflow enhancements

Added by Mark Abraham about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Jenkins
Target version:
-
Close

Description

It would be nice if [JENKINS] Release could take an optional parameter, e.g. actual or 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.

History

#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)

#3 Updated by Gerrit Code Review Bot almost 4 years ago

Gerrit received a related DRAFT patchset '1' for Issue #2066.
Uploader: Teemu Murtola ()
Change-Id: I916439c1be26823b4e366aea4e7fcded6de21659
Gerrit URL: https://gerrit.gromacs.org/6352

#4 Updated by Teemu Murtola almost 4 years ago

  • Status changed from New to Resolved

#5 Updated by Szilárd Páll over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF