Skip to content

Latest commit

 

History

History
161 lines (94 loc) · 4.59 KB

README.md

File metadata and controls

161 lines (94 loc) · 4.59 KB
Raw

CI

The repos' CI is set up using Cloud Build. Tests are run for each PR targeting master or next branches.

The CI is run in a particular GCP project (ci-builder) that the author has for this purpose.

Note: Commands in this document are intended to be executed in the ci folder.

Requirements

  • gcloud Google Cloud Platform CLI

    Installation on macOS Follow [Installing Google Cloud SDK](https://cloud.google.com/sdk/docs/install)

    After unpacking, move the folder to a permament location (author uses ~/bin/google-cloud-sdk). The installation is on that directory only, and uninstalling means removing the directory.

    $ gcloud --version
 Google Cloud SDK 343.0.0
 ...

    Update by: gcloud components update

    Installation on Windows 10 + WSL2 tbd.. `#contribute`

  • Docker

    Needed for building the builders.

GCP: CI project, Builder image

You can either finish with this document and check it later, or drop in their right now. Your CI script will eventually need the builder to exist.

GitHub: Enable App triggers

  • In GitHub Marketplace, enable the "Google Cloud Build" application
  • Add your GitHub repo to the Cloud Build app

Building manually

Make sure you are logged into the GCP project used for the Cloud Build.

$ gcloud config get-value project
ci-builder

$ gcloud builds submit ..

This packages the files (filtered by ../.gcloudignore), ships them to Cloud Build, runs the build in the cloud, and streams the output to your terminal.

It's a GREAT way to check builds when developing them. You don't need to commit changes to git until the builds work!

Setting up Triggers

We wish the CI to run tests when:

  • a new PR (or a change to an existing PR), targeting master (or next) is available.

    This will help us see, whether merging the changes is relatively safe.

Deployment of versions to npm is left to be done manually.

Trigger for PRs

Cloud Build > Triggers > Create Trigger

Something like this:

Note: The above is just a sample. Study each choice in turn, and make your own decisions.

We can test this trigger only by making a PR.

Testing the trigger

Let's make a Pull Request and see how it shows in GitHub.

$ git checkout -b temp-230521

# edit some change; eg. add white space to non-document file

$ git commit -m "testing CI"

$ git push --set-upstream origin temp-230521

Go to GitHub.

Create a pull request with the button there, mentioning the recent push.

Make a breaking change that would cause a test to fail.

$ git commit -m "break test"
$ git push

The GitHub PR page should show this:

...turning into this:

Note that the "Merge pull request" button is still available, though not highlighted.

Use of Cloud Storage (extra)

Cloud Build uses Cloud Storage (of the same project) to store files. The buckets look like this:

bucket file sizes purpose
artifacts.*/containers/images 1..25 MB (unknown)
*_cloudbuild/source/*.tgz ~33 kB source tarballs

The storage requirements are minimal, but by default there's no lifecycle rule for these files, meaning they will be kept "forever".

Here is one benefit of keeping one's CI's running on a separate GCP project - all the storage buckets we see here are connected to CI/CD runs (and therefore easier to clean).

Either:

  • forget about this :)
  • visit it once a year, and remove the buckets totally
  • add lifecycle rules that remove aged stuff

CI/CD older than a month are likely not ever needed (= 30 days and delete would be fine).

References