Creating a well-organized build or release workflow is both an art and a science. Done properly, the process can be testable and maintainable, able to work on any CI/CD system. Like many things in software, there’s even a pattern that helps!

It’s not unusual for teams to want to merge the same branch into multiple branches. If they create multiple pull requests from that branch to each of the other branches, they suddenly find that their Checks behave differently than expected and the branches start to share results. Understanding why this happens makes it easy to get Checks to behave as expected.

Most package management systems support some kind of “universal artifacts” storage. Azure Artifacts supports “universal packages”, Artifactory supports “generic repositories”, and Nexus has “raw repositories”. But what about GitHub? From all appearances, it would seem this is an oversight. Although not explicitly documented, it turns out it’s fully supported.

If you’ve ever wanted to integrate an external system or execute parts of the CI process asynchronously, the GitHub Checks API can provide a way to make that happen. In fact, you can even use Checks to allow two workflows to work together, no waiting or polling from the runner required. Today I’ll demonstrate how the API works and provide two workflows that demonstrate how to build a working GitHub Check.

Most people don’t realize that the humble pull request orchestrates surprisingly complex activities behind the scene. GitHub creates test merges and simulated merge branches to test and validate what would happen if the changes were merged into the target branch. This is more complex than most people realize, and it leads to a number of different SHAs being provided to the GitHub workflow. It’s time to understand these SHAs, their purpose, and how to find them.

Monorepos are often seen as the simple solution to complex collaboration and code management problems. Companies like Google and Facebook frequently mention their use of the pattern for their most important codebases, so clearly they have found ways to make these solutions scale to support large teams. What is their secret to being able to successfully use a monorepo, and how do they make it work where so many others fail? More importantly, should you be considering the approach?

GitHub supports defining a repository as a template. This enables you to configure a repository, its contents, and its branches quickly. But it can do more…

GitHub Actions Workflows can provide a great abstraction layer for creating or orchestrating build and release processes. Since we’re running code – in some cases, from third-parties – it’s important to understand how to secure the environment from malicious Actions. This is where permissions can help.

GitHub Actions allows you to create matrix builds to execute steps multiple times with different parameters. Fun tip – those parameters can be dynamic. You can define them programmatically!

Java makes it surprisingly easy to manage and package complex projects using Apache Maven. One question I’m frequently asked – how does this integrate with GitHub Actions? Turns out that the answer is “surprisingly well!”