Conversation
| All the release scripts assume they're releasing to master. For a stable release, additional parameters are needed. All of the above scripts accept parameters. The first is the directory where to execute. To create a release PR for the current directory to the 11.1-stable branch: | ||
|
|
||
| ```console | ||
| $ ../../bin/release-pr . 11.1-stable |
There was a problem hiding this comment.
This assumes you have this structure, correct?
foreman-installer-module-sync
├── modules
│ └── puppet-foreman_proxy_content
That's not clear from the README. Is there a script or command that sets this up?
There was a problem hiding this comment.
I ran this, and this was the output (with no changes):
ehelms@war puppet-foreman_proxy_content (master)$ ../../bin/release-pr . 11.1-stable
Switched to a new branch 'release-12.0.0'
On branch release-12.0.0
nothing to commit, working tree clean
There was a problem hiding this comment.
This assumes you have this structure, correct?
Well yes, but it already did that before. Just keeping things consistent. Technically you can also run it from the root as ./bin/release-pr modules/puppet-foreman_proxy_content 11.1-stable but I always like to work in the directory so you have tools like git diff.
I ran this, and this was the output (with no changes):
It is intended that you run this instead of the others. So what I always did was git checkout 11.1-stable, build up a changelog (often manually because it was easier than using the tool), then ran this. You may also need to run bundle install or bundle update.
There was a problem hiding this comment.
What does build up a changelog mean? Manually adding the entries in the CHANGELOG file?
There was a problem hiding this comment.
I've rewritten it a bit. Please have a look at the latest version.
|
|
||
| All the release scripts assume they're releasing to master. For a stable release, additional parameters are needed. All of the above scripts accept parameters. The first is the directory where to execute. | ||
|
|
||
| To create a release PR for the current directory to the 11.1-stable branch, first get your working directory set up correctly. This means that git should point to the correct code and `CHANGELOG.md` is prepared. Bundler should also have all gems installs. In the regular workflow, the `changelogs` command does this, but [Github Changelog Generator](https://github.com/github-changelog-generator/github-changelog-generator) doesn't really support non-linear releases (with branches) so in practice it's easier to do so by hand. |
There was a problem hiding this comment.
| To create a release PR for the current directory to the 11.1-stable branch, first get your working directory set up correctly. This means that git should point to the correct code and `CHANGELOG.md` is prepared. Bundler should also have all gems installs. In the regular workflow, the `changelogs` command does this, but [Github Changelog Generator](https://github.com/github-changelog-generator/github-changelog-generator) doesn't really support non-linear releases (with branches) so in practice it's easier to do so by hand. | |
| To create a release PR for the current directory to the 11.1-stable branch, first get your working directory set up correctly. This means that git should point to the correct code and `CHANGELOG.md` is prepared. Bundler should also have all gems installed. In the regular workflow, the `changelogs` command does this, but [Github Changelog Generator](https://github.com/github-changelog-generator/github-changelog-generator) doesn't really support non-linear releases (with branches) so in practice it's easier to do so by hand. |
There was a problem hiding this comment.
If I read this paragraph I still find I am not sure what to do with respect to "git should point to the correct code" and "CHANGELOG.md is prepared". I think this is complicated by the previous release sections that talk about generating a changelog. Does this translate to:
- Create a release branch based on the X.Y version you are releasing, e.g. 11.1-stable
- Cherry pick changes into the release branch via PRs
- Open a PR that bumps the version, and modifies the CHANGELOG. This is done manually by the releaser.
There was a problem hiding this comment.
Well, that's what you get when you write documentation at the end of a Friday afternoon ;)
2 participants
No description provided.