An example of a golang-based monorepo.
|GitHub Actions|CircleCI| |:-----|:------| |
|
|
(This repo is mirrored to https://codeberg.org/flowerinthenight/golang-monorepo).
Overview
This is an example of a golang-based monorepo. It has the following features:
- Only build the services or cmds that are modified in a commit;
- Build all services and/or cmds that are affected by changes in common codes (i.e.
internal); - Build all services and/or cmds that are affected by changes in
vendorcodes.
At the moment, CI is setup with GO111MODULE=on and GOFLAGS=-mod=vendor environment variables enabled during build. See sample dockerfile.samplesvc for more details.
How does it work
During CI builds, build.sh iterates the updated files within the commit range (CIRCLECOMPAREURL environment variable in CircleCI) or the modified files within a single commit (when the value is not a valid range), excluding hidden files, internal, and vendor folders. It will then try to walk up the directory path until it can find a Makefile (excluding root Makefile). Once found, the root Makefile will include that Makefile and call the custom rule as target, thus, initiating the build.
When the changes belong to either internal or vendor, the script will then try to determine the services (and cmds) that have dependencies using the go list command. All dependent services will then be built using the same process described above.
You can override the COMMITRANGE environment variable for your own CI. If this is set, build.sh will use its value. You also want to set CIRCLESHA1 to your commit SHA (CIRCLESHA1 is CircleCI-specific). Example for GitHub Actions is here. Something like:
# If your commit range is correct:
COMMIT_RANGE: aaaaa..bbbbb
CIRCLE_SHA1: aaaaa
If no valid commit range:
COMMITRANGE: <yourcommit_sha>
CIRCLESHA1: <yourcommit_sha>Directory structure
services/- Basically, long running services.cmd/- CLI-based tools that are not long running.internal/- Shared codes, or libraries common across the repo.vendor/- Third party codes from different vendors.
[!IMPORTANT]
Although we have this structure, there is no limitation into where to put your services/cmds. Any subdirectory structure is fine as long as a Makefile is provided.
How to add a service/cmd
A reference template named samplesvc is provided. Basically, these are the things that you need to do:
- Create a new directory for your service under
services/or tool undercmd/. You may copy thesamplesvccontents to your new directory. - Update the
dockerfile.{name}inside your new service directory. Note that during build, thisdockerfile.{name}is copied to the root directory (to be able to accessinternalandvendordirectories). - Update the
Makefilewith your own values. You need to at least update theMODULEvariable with your service name. The only required rule is thecustompart so you may need to change that as well (i.e. name of thedockerfile.{name}used indocker build). - [Optional] Update the
deploy.shscript for your deployment needs.
