Preview releases with pull requests
This recipe always keeps an open pull request which previews the changes that Knope will include in the next release. This pull request will let you see the next version, the changes to versioned files, and the changelog. When you merge that pull request, Knope will create a new release with the changes from the pull request.
This recipe requires a custom knope.toml
file and two GitHub Actions workflows.
knope.toml
Each section below is separate for easier explanation, but all these TOML snippets exist in the same file.
[package]
This first piece defines the package.
versioned_files
are how Knope determines the current package version, and where it puts the new one.
Knope will describe the changes in the changelog
file in addition to GitHub releases.
Knope will expand the assets
glob and upload any matching files to the GitHub release.
You can also specify assets individually.
prepare-release
workflow
The first workflow has a name
of prepare-release
,
so knope prepare-release
will execute it (the GitHub Actions workflow will contain this command).
First, it creates a new branch from the current one called release
.
Next, it runs the PrepareRelease
step, which updates the package based on the changes made since the last release.
It also stages all those changes with Git (like git add
).
Next, the workflow commits the changes that PrepareRelease
made—things like:
- Updating the version in
Cargo.toml
andCargo.lock
- Adding a new section to
CHANGELOG.md
with the latest release notes - Deleting any changesets
The workflow then pushes the commit to the release
branch,
using the --force
flag in this case because the history of that branch isn’t important.
The CreatePullRequest
step then creates a pull request from the current branch
(release
) to the specified base branch (main
).
It uses string templates containing variables to set the title and body,
in this case, the title includes the new Version
and the body includes the new ChangelogEntry
.
The pull request that this creates looks something like this:
release
workflow
The release
workflow is a single Release
step—this creates a GitHub release for the latest version
(if it doesn’t already exist) and uploads any assets.
In this case, it’ll create a release for whatever the prepare-release
workflow prepared earlier.
GitHub Actions will run this workflow whenever someone merges the pull request (created by prepare-release
).
[github]
The last piece is to tell Knope which GitHub repo to use for creating pull requests and releases. You must substitute your own values here:
prepare_release.yaml
There are two GitHub Actions workflows for this recipe—the first one goes in .github/workflows/prepare_release.yaml
and it creates a fresh release preview pull request on every push to the main
branch:
The steps here:
- Check out the entire history of the repo (so that
PrepareRelease
can use tags and conventional commits to pick the next version). This requires a personal access token with permission to read the contents of the repo. - Configure Git so that the job can commit changes (within Knope’s
prepare-release
workflow) - Install Knope
- Run the
prepare-release
workflow described earlier. This requires a personal access token with permission to write the pull requests of the repo.
In this example, the same personal access token is in both steps, but you could use separate ones if you wanted to.
release.yaml
Now that Knope is creating pull requests every push to main
,
it needs to automatically release those changes when a pull request merges.
This is the job of the release
workflow, which goes in .github/workflows/release.yaml
.
To start off, this workflow must only run when release preview pull requests merge—there are several pieces of config that handle this. First:
Will cause GitHub Actions to only trigger the workflow when a pull request which targets main
closes.
Then, in the first job, an if
narrows that down further to only release preview pull requests,
and only when they merge (not close for other reasons):
If you have assets to upload, you’ll want a build-artifacts
job which runs before the next step.
Skipping on past that job (since it probably will be different for you), the next one is the release
job:
The release
job follows these steps:
- Check out the repo at the commit that the pull request merged
- Download the artifacts from the
build-artifacts
job - Install Knope
- Run the
release
workflow described earlier. This requires a personal access token with permission to write the contents of the repo.
Finally, our example workflow publishes to crates.io—meaning the whole workflow looks like this:
Conclusion
Just to summarize, this recipe describes a process that:
- Automatically creates a pull request in GitHub every time a new commit is pushed to
main
. That pull request contains a preview of the next release. - Automatically releases the package every time a release preview’s pull request is merged.