nchlswhttkr / mandarin-duck

Trigger Buildkite pipelines from a self-hosted Git repository

G'day, I'm Nicholas! 👋

I'm a developer with a love for web development and automation.

At the moment, I'm helping organise logistics with the awesome crew at UNIHACK.

You can read posts about my interests on my blog or via my RSS feed. I tend to write about music, weekend projects and short technical dives into the software I use.

When I'm not coding, I'm likely playing brass/piano or at band rehearsal! 🎵 🎵 🎵

---

If you'd like reach me, you can find me on the following places. My email is on the sidebar to the left!

Website • Twitter • LinkedIn

mandarin-duck's Issues

Verify provided path to installer is a Git repo

At the moment, install.sh assumes that the provided path is a Git repository. It would be better to verify this at runtime.

Additionally, the repo should be actually be a bare repo with the hooks directory at the root.

Add option to create pipeline when adding a new repository

Depends on #2

If a BUILDKITE_API_TOKEN is passed in with the installation process, it's possible to create a new pipeline for the given repo.

It might require some initial introspection, to make sure the token has write_pipelines permission. If it only has write_builds permission, the step should skip.

Skip triggering build on deleted branches

Pushing deleted branches currently triggers a build because it calls the post-receive hook. Of course, this build fails because the branch no longer exists.

Add logic in to identify delete branches and skip triggering a build.

git push --delete origin create-test-harness
# remote: --- Triggering Buildkite build on create-test-harness
# remote: You can view this build at https://buildkite.com/nchlswhttkr/mandarin-duck/builds/15
# To 123.123.123.123:/var/www/git/mandarin-duck.git
#  - [deleted]         create-test-harness

Support installing hooks for multiple repos at once

It would be convenient if the install.sh could add hooks for multiple repos at once.

./install.sh /srv/git/repo-1.git /srv/git/repo-2.git /srv/git/repo-3.git

This would add all three repos to the mandarin-duck.cfg config and create the post-receive hook for all of them.

Handle failure when calling the Buildkite API

It's good that the post-receive.sh script checks for required Buildkite-related environment variables before running.

However, it doesn't do anything to handle the Buildkite API responding with a 4XX/5XX error when called. It would be good to capture the error code (with/without the message body) and show it in the hook output.

In addition to this, it would be good to think about what mandarin-duck should do WRT logs/errors - where do they get written?

Add an update pathway to the install script

Ideally if install.sh is run on a machine that's already been set up but is outdated, the existing config and script should be upgraded.

It's possible to determine the current version from mandarin-duck.cfg, which has a .version field. I'm only doing major.minor versioning rather than semver, but this still gives enough flexibility to handle disruptive/breaking changes and smooth changes.

So long as the major version doesn't change, mandarin-duck should automatically update itself. As for when the major version does change, I'm fine leaving that as an unknown for now and dealing with it when (if ever) I need to make a breaking change.

Revoke Buildkite API token on uninstall

As a matter of good practice, the Buildkite API token used by mandarin-duck could be revoked/rotated as part of the uninstall process. The Buildkite API allows a token to revoke itself.

This should probably be optional though, as a revoking a token this project didn't create could be an annoyance/inconvenience for users.

With that said, if the installation docs specifically encourage creating a token for mandarin-duck's use only then it's sensible to revoke it during an uninstall.

Handle [skip ci] in commit messages

This is doesn't seem like it is required, since Buildkite already ignores commits with the [skip ci]/[ci skip] keyword. It may technically run though, seeing as Buildkite doesn't know the commit message until a build is started and the pipeline upload step runs. The post-receive.sh script doesn't include it in the API call to trigger a build.

Handling/acknowledging the keyword in the post-receive hook seems like a good safeguard. It ensures Buildkite isn't called, and lets the server communicate as much.

Should pushing tags trigger a build?

I've only done testing so far by pushing on one/many branches. However, mandarin-duck should be able to handle tags being pushed too.

Presumably, they should trigger a build too. Whether they have slightly different behaviour depends on what this investigation turns up.

Given pushing a tag is similar to pushing a branch (they're both refs), it might already be handled fine. This is something to verify first though.

Populate config information from environment variables

The current install process requires some values to be added manually after the mandarin-duck.cfg config file is created. This makes the first-time install process quite cumbersome.

It would be nice if some/all of these values could be populated from environment variables. For example:

BUILDKITE_AGENT_TOKEN=abc123 ./install.sh /var/www/git/mandarin-duck.git

There are three values that need to be populated at the moment:

• BUILDKITE_API_TOKEN
• BUILDKITE_ORGANIZATION_SLUG
• BUILDKITE_PIPELINE_SLUG

The main one is the API token. Once it's possible to pass that in via an environment variable, it might be worth considering whether org/pipeline values can be obtained via API calls. 🤔