I wrote about how Tools are not solutions. Today I have another story for you that can be summarized with “don’t get married to your solution”. We are used to setting up GitHub workflows with a trigger like:

• Push to master
• Push to a branch
• issue comment
• tag created

But sometimes a trigger is not obvious, or it ends up being wrong.

Last year I created a workflow that sends a message when a new PR gets created sharing that there is a custom commands called /push-container useful to build a container from a pull request with a simple comment.

I thought it was a smart move, everyone creating a pull request will get a reminder about the custom capabilities available in such repository.

Fast-forward, fix months later I have 8 new teammates, only one working directly on repositories with these capabilities. The outcome is that for each pull requests we get:

• an email saying that there is a new PR
• An email saying that there is a new commend (the one written by the automation)
• Another one saying that a new workflow completed (the one that wrote the comment)
• Another one saying that a new workflow completed/succeeded (the continuous integration workflow we have in place)

Annoying… but I was used to it, I didn’t even notice but my teammate did! And it hated it! Luckily he is a good person and didn’t tell me that, but we ended up not porting this solution to other repositories. He didn’t do it, I didn’t do it as well. At the end I need to build and push locally, or I won’t do it at all. Pretty bad outcome.

This is the perfect signal that an idea is wrong not because it does not work but because your user base does not like it.

I still want to have a workflow that builds a container because we have many private repositories across cloud providers, and it is not that easy to tag, build and login everywhere, it is also a security risk that I can avoid centralizing the authentication in a single location.

Something I learned along the way and that we use in another repository is the approach of manually triggered workflows. We use that to run smoke tests across different environments.

I think that’s a better solution for my use case. The initial “comment base approach” comes from my experience as Kubernetes Release Eng, there everything is managed via comment but the ratio of contributors per contributions is different.

The only difference is that compared with receiving the same email over and over if you want to discover the capabilities you have for a specific repository you need to open the Action tab to see what you can manually run. The workflow accepts inputs, so you can stick there the SHA you want to see built, and here you are, let’s see if this will work or not.

This won’t be the final solution but hey, it works better for us!

If you have suggestions, I am happy to know them but try to do it without adding a new tool to your tool chain!