[CI] Use src/VERSION for maintenance build on release branch
#11522
Conversation
| # We need to sanitize it because there are restrictions on some places | ||
| # where the version is use (Mac pkg names, snap branch). | ||
| VERSION=${VERSION//_/-} | ||
| VERSION=${VERSION//\//-}-dev |
There was a problem hiding this comment.
This should be applied unconditionally I guess (to be on the safe side).
There was a problem hiding this comment.
I figure if src/VERSION has underscores or slashes, we're in more trouble anyways. So this isn't technically necessary.
|
What would be the process to incremente the package iteration? I was expecting to see a variable or a new file for that. Would this work if two new package iteration are wanted for the same minor version (but different patch version)? I guess yes as long as each minor has its release branch when needed. Currently is not the case. I thought we had a check to use version numbers only on tagged releases. But is the other way around: tagged commits must match version file (bin/ci takes care of this). We are good. I'm not sure if snap will like two packages with the same version, but lets see how it goes. Worst case there is a need to manually yank the previous release. |
|
Yeah we currently don't have any way to express package iterations. I don't think an indication is commonly used for docker images. But there you have at an easy means to identify different images by their hash id.
I suppose we could do that. But I'm not sure it makes much sense. In my opinion, after a patch is released, all prior patch releases of the x.y branch are outdated. I don't think it makes sense to support more than one patch release for any minor release branch simultaneously.
I have no idea how this works out for snap. I'm not familiar with that at all. |
In a release branch, maintenance builds should pull the version from
src/VERSIONinstead of the branch name. That allows us to build package increments from a release branch. A use case example would be crystal-lang/distribution-scripts#170: It changes the distribution package, but not the actual Crystal release. We would like to update and replace the 1.2.2 releases with this package increment.The changes are pulled into the release branch in #11515. This also triggers a maintenance build, but it's tagged as a dev build. With this patch, we can directly publish the build artifacts from that maintenance build because they're properly tagged as 1.2.2.
I pushed the same commit to two different branches to show the difference:
release/test:CRYSTAL_VERSION=1.3.0-dev(it's not 1.2.2 because the commit is based on master, notrelease/1.2). https://app.circleci.com/pipelines/github/crystal-lang/crystal/7508/workflows/52f74a17-2f10-4318-9182-170072bd9209/jobs/66143ci/maintenance-release-version:CRYSTAL_VERSION=ci-maintenance-release-version-devhttps://app.circleci.com/pipelines/github/crystal-lang/crystal/7507/workflows/a53736f8-23ed-4039-a36a-8505c414808a/jobs/66142
The workflows for tagged and maintenance releases are identical except for the prepare step. So the build should be functionally identical, whether it's from a tagged commit or a non-tagged commit in a release branch.
Since the version is identical to the last tagged release, the workflow will automatically publish docker images with the respective tag. I'm not sure if we should keep it that way or use different tags for the docker images and require manual promotion to avoid accidental overrides.