I spent a few hours automating my software release process because it was driving me a bit crazy. And of course, I wrote how I did it:
7 Likes
Neat! This gives me some ideas for better automating some of my releases 
They’ve been mostly automated, save for me using a QEMU VM to build an AppImage, and me wanting to handle the changelog manually.
1 Like
I have decided I am not disciplined enough to keep the changelog properly :-)
2 Likes
I suffered the same, then decided to enforce it on myself and use changie to handle it for me:
- Only accept contributions via PR (rules on the repo)
- Each PR should have at least one changelog fragment: .github/workflows/check-changelog.yml
- When ready, manually trigger a release workflow, which creates a release PR: .github/workflows/create-release-pr.yml
- The release gets created by detecting changes to
CHANGELOG.md, which then creates the git tag and attach the release notes to the GH release: .github/workflows/release.yml
I’ve used this for some non-public projects and worked good for me, at least avoids me pushing broken code part of the release 
Cheers!
2 Likes
What you do almost same as ritual gem, but for publish to Rubygems site, you have to add an item like == LATEST into ./CHANGLOG, and when do rake task to publish gem, it will be replaced with correct date.
Create a same tools for publish GH release is quite easy (even easy than ritual), I think I would create that tool when I need it.
Yes, it does a similar thing, except without the changelog management.
It have?
if you are not add a item which following the pattern like below into ./CHANGELOG, any rake task will failed. (check screenshot)
But it does that when you want to do a release, right?
The tool I am using doesn’t require any interaction to make a release because it extracts the changelog from the git commit log
1 Like
Never mind discipline, I have enough problem remembering.
I use Emacs, and do all my giting through magit. So I told magit to check if there’s a changelog I forgot to change and ask me if I’m sure.
And after fumbling with releases a few times, I wrote myself a small tool. Like your script, it updates shard.yml, tags and commits, but updates the changelog too. I’ve invented a small extension of the keep a changelog format, so the next version number is recorded in the changelog. It’s when I add the changelog entry for a change that I know if it warrants a patch, minor or major release (which is when I commit the change, due to the above hack), so updating it there makes sense.
While observing various GitHub repositories in the declining Ruby community, I noticed which projects continued and which did not. This observation led me to believe that there is an interesting inverse relationship between a project’s “discipline” and its “longevity.” (Of course, this is just my personal opinion and not based on concrete data!)
While automation and discipline are important, I also think it is necessary to accept some level of inconsistency and imperfection. Otherwise, we may always find ourselves dissatisfied.
Why so many users use Makefiles? Because the syntax is the same on all of POSIX systems, so I don’t understand why I will need to use a new one tool…
Makefiles are not great for some things.
For example: I want to have two tasks that generate the same binary but compiled with different flags. Usually with Makefiles that involves setting flags in the CLI, which is very verbose and easy to get wrong.
Another issue is that make only looks at timestamps to decide if tasks are out of date, while I prefer to depend on file contents.
Or that in order to use wildcards in dependencies in Makefiles you are actually using a GNU extension so it’s not a “normal” Makefile
Also, I wrote this other tool because I like the way it works, everyone else can keep on using Makefiles and be happy with them :-)
task can use file checksums.
As much as I like YAML, I think it was a mistake to base the Taskfile format on it.
There is nothing really interesting about the file being yaml, it could just as easily be anything else, it’s just for deserialization convenience at this point.
Also hacé is a testbed for GitHub - ralsina/croupier: A library to create and execute tasks with dependencies which I really wanted to exercise to get the bugs out