Today I released version 0.38.0 of the GitHub Action for doing spelling checking of your documentation etc. for which I am the current maintainer.
- Docker base image bumped to Python 3.12.4
As mentioned in the announcement for the previous release (0.37.0
) the release process requires lot of steps. With this release it was made almost entirely using the mentioned Perl script.
The current version here:
#!/usr/bin/env perl
use warnings;
use strict;
use v5.10.0;
my $version = $ARGV[0];
if (not $version) {
die 'Usage build.pl <version>';
}
say "Building Docker images for version: $version";
my @targets = qw(v0 latest);
push @targets, $version;
say 'Building Docker images for amd64 architecture';
my $counter = 0;
my $total = scalar @targets;
foreach my $target (@targets) {
say "Building $target ($counter/$total)";
system "docker build --platform linux/amd64 --tag jonasbn/github-action-spellcheck:$target .";
$counter++;
}
$counter = 0;
say "Pushing Docker images to DockerHub";
foreach my $target (@targets) {
say "Pushing $target ($counter/$total)";
system "docker push jonasbn/github-action-spellcheck:$target";
$counter++;
}
# Updating the v0 tag
say 'Deleting existing tag v0 locally';
say 'git tag --delete v0';
system 'git tag --delete v0';
say 'Deleting existing tag v0 remotely';
say 'git push --delete origin v0';
system 'git push --delete origin v0';
say 'Tagging also as v0';
say 'git tag --annotate v0 --message "Tagging v0"';
system 'git tag --annotate v0 --message "Tagging v0"';
# Pushing tags
say 'Pushing tags';
say 'git push --tags';
system 'git push --tags';
# The tagging of the version number is a part of the release process, so not need
# to create this tag separately
say 'Creating release on GitHub with auto generated release notes and discussion';
system "gh release create $version --discussion-category 'General' --generate-notes";
exit 0;
REF: GitHub
This script is run like this:
$ perl scripts/build.pl 0.38.0
The script takes a version number and basically automate large parts of the release process outlined in the wiki.
First it adds the version number to a list of tags, which are the images we want to build.
So we build:
-
0.38.0
(the number provided as an argument -
v0
our canonical version, since we want it to point to the latest release (see: the version number notes in the wiki -
latest
a symbolic tag, point to the latest release
Next the 3 freshly build Docker images are pushed to DockerHub.
We then delete the current v0
Git tag locally and remotely.
Then we tag v0
again, locally and remotely.
Finally we cheat and use gh
(the GitHub CLI client).
Using this we create a release, open a discussion and I found out with the previous release, it actually creates the version tag, in this example meaning: 0.38.0
.
The script might not be completely rock-solid, I am thinking about using Perl's autodie, which I would perhaps be a good fit in this context.
I still have a few manual steps.
- The examples in README.md reflect the version to be released
- The version pointed to in
action.yml
reflect the version to be released
Which can also be solved programmatically.
Finally as mentioned in the previous post, instead of a script a GitHub Action would be a preferable solution.
Ideas, PRs, bug reports and general feedback always welcome
Change Log
0.38.0, 2024-06-13, maintenance release, update not required
- Docker image updated to Python 3.12.4 slim via PR #202 from Dependabot. Release notes for Python 3.12.4
Top comments (0)