@@ -12,8 +12,11 @@ export RELEASE_VERSION="X.Y.Z"
1212git switch main
1313git pull -r
1414git switch -c release-v$RELEASE_VERSION
15+
1516bundle config set --local path vendor/bundle
17+ bundle config set --local with ' release'
1618bundle install
19+
1720CHANGELOG_GITHUB_TOKEN=" token_MC_tokenface" bundle exec rake changelog
1821git commit -am " Release v${RELEASE_VERSION} "
1922git push origin release-v$RELEASE_VERSION
@@ -26,24 +29,6 @@ Then open a PR, discuss and merge.
2629``` shell
2730git switch main
2831git pull -r
29- git tag v$RELEASE_VERSION
32+ git tag v$RELEASE_VERSION -m " v $RELEASE_VERSION "
3033git push --tags
3134```
32-
33- ## Tags
34-
35- Each puppetserver and puppetdb is accompanied by a build_versions.json file
36- containing information about puppet releases and versions built when a tag is pushed or a change is made to the main branch.
37-
38- To enhance clarity and organization, we are transitioning from our previous tagging approach
39- and will now distinguish the container tag from the puppet version.
40- The new tags will follow the format vX.Y.Z. The CI build process operates within a matrix,
41- leveraging the data from the JSON file to construct the specified versions.
42- As a result, two Docker tags are currently generated: 7.13.0-vX.Y.Z corresponds to
43- the Puppet Release 7.13.0 build with container version X.Y.Z, while 8.10.0-vX.Y.Z aligns
44- with Release 8.10.0. These tags offer a more streamlined and informative representation of our build versions.
45-
46- The container tags like ` 7.13.0-main ` and ` 8.10.0-main ` are built automatically
47- whenever changes are merged into the Git main branch.
48- It's important to note that these tags are designated as development tags
49- and might be subject to breakage, so exercise caution when using them.
0 commit comments