coop-cloud/docs.coopcloud.tech
coop-cloud
/
docs.coopcloud.tech
4
1
Fork 14
Code Issues Pull Requests 2 Releases Activity
docs.coopcloud.tech/docs/abra/hack.md

3.7 KiB
Raw Blame History

title
Hack

Quick start

Get a fresh copy of the abra source code from here.

Install direnv, run cp .envrc.sample .envrc, then run direnv allow in this directory. This will set coopcloud repos as private due to this bug.. Or you can run go env -w GOPRIVATE=coopcloud.tech but I'm not sure how persistent this is.

Install Go >= 1.16 and then:

  • make build to build
  • ./abra to run commands
  • make test will run tests
  • make install will install it to $GOPATH/bin
  • go get <package> and go mod tidy to add a new dependency

Our Drone CI configuration runs a number of sanity on each pushed commit. See the Makefile for more handy targets.

Please use the conventional commit format for your commits so we can automate our change log.

Cross-compiling

If there's no official release for the architecture you use, you can cross-compile abra very easily. Clone the source code from here and then:

  • enter the abra directory
  • run git tag -l to see the list of tags, choose the latest one
  • run git checkout <tag>, where <tag> is the latest version
  • run GOOS=<os> GOARCH=<arch> [GOARM=<arm>] make build. You only have to use GOARM if you're building for ARM, this specifies the ARM version (5,6,7 etc). See this for a list of all supported OS'es and architectures.

Release management

We use goreleaser to help us automate releases. We use semver for versioning all releases of the tool. While we are still in the public beta release phase, we will maintain a 0.y.z-beta format. Change logs are generated from our commit logs. We are still working this out and aim to refine our release praxis as we go.

For developers, while using this -beta format, the y part is the "major" version part. So, if you make breaking changes, you increment that and not the x part. So, if you're on 0.1.0-beta, then you'd go to 0.1.1-beta for a backwards compatible change and 0.2.0-beta for a backwards incompatible change.

Making a new release

  • Change ABRA_VERSION to match the new tag in scripts (use semver)
  • Commit that change (e.g. git commit -m 'chore: publish next tag x.y.z-beta')
  • Make a new tag (e.g. git tag -a x.y.z-beta)
  • Push the new tag (e.g. git push && git push --tags)
  • Wait until the build finishes on build.coopcloud.tech
  • Deploy the new installer script (e.g. cd ./scripts/installer && make)
  • Check the release worked, (e.g. abra upgrade; abra -v)

Fork maintenance

godotenv

We maintain a fork of godotenv because we need inline comment parsing for environment files. You can upgrade the version here by running go get github.com/Autonomic-Cooperative/godotenv@<commit> where <commit> is the latest commit you want to pin to. At time of writing, go get github.com/Autonomic-Cooperative/godotenv@b031ea1211e7fd297af4c7747ffb562ebe00cd33 is the command you want to run to maintain the above functionality.

docker/client

A number of modules in pkg/upstream are copy/pasta'd from the upstream docker/docker/client. We had to do this because upstream are not exposing their API as public.