Skip to content

Document the stable release workflow #127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ekohl wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Document the stable release workflow #127

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,26 @@ If someone already merged it but didn't release it, then it can be released:
$ ../../bin/release-module
```

### Stable releases

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.
Copy link
Copy Markdown
Member

@ehelms ehelms Aug 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Copy Markdown
Member

@ehelms ehelms Aug 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Create a release branch based on the X.Y version you are releasing, e.g. 11.1-stable
  2. Cherry pick changes into the release branch via PRs
  3. Open a PR that bumps the version, and modifies the CHANGELOG. This is done manually by the releaser.

Copy link
Copy Markdown
Member Author

@ekohl ekohl Aug 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, that's what you get when you write documentation at the end of a Friday afternoon ;)


Once all the code is prepared, a PR should be submitted:

```console
$ ../../bin/release-pr . 11.1-stable
Copy link
Copy Markdown
Member

@ehelms ehelms Aug 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

@ehelms ehelms Aug 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

@ekohl ekohl Aug 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@ehelms ehelms Aug 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does build up a changelog mean? Manually adding the entries in the CHANGELOG file?

Copy link
Copy Markdown
Member Author

@ekohl ekohl Aug 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rewritten it a bit. Please have a look at the latest version.

```

Once approved, merging also accepts the same arguments:

```console
$ ../../bin/release-merge . 11.1-stable
```

`release-module` performs no git operations and behaves the same regardless of stable/master. `release-merge` already calls it so it's not documented here.

### Short Bulk Release Workflow

This repository also contains scripts to easy module releases. This short workflow:
Expand Down