I had used “Sourcegraph Campaigns” once that I migrated all of my personal repositories from Travis CI to GitHub Actions, which is now branded as Sourcegraph Batch Changes. If this is the first time you heard about it, it is, in my own words, a toolset to create and manage content changes across many, could be dozens if not thousands of repositories.
This time, I want to run tests in CI with Go 1.17 for all of Flamego’s repositories, in addition to Go 1.16 (because Go 1.17 wasn’t released at the time).
I will not replicate what has been well-documented in the Batch Changes documentation, and simply putting links to the relevant sections here. To use Batch Changes, I need:
Most of typing is done through writing the spec file for the Batch Changes to produce changesets, the following is what I have:
# File: add-go-1.17-to-flamego-ci.batch.yaml name: add-go-1.17-to-flamego-ci description: This batch change adds Go 1.17 to CI for all Flamego repositories # Find all Flamego repositories that contain the CI file I want to change. on: - repositoriesMatchingQuery: "repo:github.com/flamego/ file:go.yml go-version: [ 1.16.x ]" # In each repository steps: - run: "sed -i 's/go-version: \\[ 1.16.x \\]/go-version: \\[ 1.16.x, 1.17.x \\]/' .github/workflows/go.yml" container: alpine:3 # Describe the GitHub pull request I want for each repository. changesetTemplate: title: 'ci: add Go 1.17' body: Updates CI to include Go 1.17 branch: batch-changes/add-go-1.17 # Push the commit to this branch. commit: message: Add Go 1.17 to CI published: false
There is only one step in my case, which is replacing all
go-version: [ 1.16.x ] with
go-version: [ 1.16.x, 1.17.x ] in the
.github/workflows/go.yml file, for every repository that matches the search query
repo:github.com/flamego/ file:go.yml go-version: [ 1.16.x ].
To generate the changesets, I executed the following command:
$ src batch preview -f add-go-1.17-to-flamego-ci.batch.yaml
This command prints the URL that I can click to preview the changesets, neat!
I can click on each item and inspect the actual diff that will be applied:
All looks good, so I go ahead and apply them:
Honestly, I don’t know what would happen exactly if I choose to publish a changeset, so I start with selecting one of them and make it be published:
It failed. 😂
OK… I removed the last line
published: false from my spec file, and start over.
Which failed again 😇 because my GitHub Personal Access Token is missing the
workflow scope, and it is required for changing files that affects GitHub Actions. Then I granted the
workflow scope to the Personal Access Token on GitHub.com, things start to work!
Waiting all checks to pass:
Now I have confidence in Batch Changes, let’s publish all the changesets and see what happens.
Here is the side-by-side comparison between Batch Changes UI and the GitHub.com:
Here is how it looks like in Batch Changes UI if the CI failed for the pull request:
I am making progress!
Batch Changes changesets are no magic but regular pull requests, so I can make direct pushes to the pull request for fixing little things:
All done and it’s time to close the Batch Changes.
There is no last words.