Skip to content

Latest commit

 

History

History
59 lines (38 loc) · 4.38 KB

CONTRIBUTING.md

File metadata and controls

59 lines (38 loc) · 4.38 KB

CONTRIBUTING

Contributions are always welcome, no matter how large or small. Before contributing, please read the code of conduct.

Development

Linting

ShellCheck usage is recommended, however it is not enforced.

Tests

We have a set of automated tests in ./tests. These are bats tests that we use to make assertions not only on the correct functioning of our bash/shell scripts, but also of the software provided by our Docker image. Any fix or feature should be accompanied by a set of tests to validate that those changes work as expected. For an overview on how bats works see here.

Developing

We provide a Makefile with a set of utility targets to help with development.

Some examples:

  • make test build the test docker image and run the tests in TAP fromat.
  • make test-local creates a volume of the tests directory and the build scripts and run the tests inside the container. Useful when developing locally.
  • make test-local FILTER=<regex> provide a filter regex string to your test execution in order to select a specific set of tests.
  • make run build the base image and run a bash shell in a container based in it in interactive mode.
  • make run-local volume the build scripts and run a bash shell in a container based in the build image.

Our changelog is powered by an automated release-please action, which relies on commits following the conventional commit format. For the CI validation to succeed, make sure that your PRs and commits follow the conventional commits format.

CI

The bulk of our CI work takes place in Circle CI.

If you're part of the Netlify org and have write access to the repo, our pipeline will take care of:

If you don't have write access to the repo and are submitting a PR via a forked repo, the CI pipeline will still execute for you. The main difference is that it won't push your built image to our docker repo. If required, someone with write accesss to the repo can trigger the push for you. If you require it (mainly useful for testing purposes) reach out to someone on the team 👍

Releasing

  1. Create two PRs, one branching off focal and one branching off xenial, with your changes applied to each.
  2. Once the PRs are approved, merge them into their respective base branches. The merge commit should also follow the conventional commit format.
  3. Commits which are prefaced withb fix: or feat: will trigger package release PRs created by release-please. Merge these PRs. If you need to manually trigger a release-please PR you can bump the version by creating an empty PR.
  4. Wait for the CI pipelines to finish. Renovate should automatically create a PR in buildbot with the latest build-image releases (this may not happen straight away, but you can speed it up by checking the box in this PR or manually create a PR to bump the version).
  5. Review, test and deploy the PR in buildbot.

Running Test buildbot Releases

If you want to test a particular build-image change before going through the regular release process, you can do so by creating a PR following the process above :point-up: and pointing to any build-image you want. Any branch creates a valid build-image tag in the docker registry. Once the PR in buildbot is created, you can test your build-image change by referring to buildbot's test instructions.

License

By contributing to Netlify's build-image, you agree that your contributions will be licensed under its MIT license.