Skip to content

Latest commit

 

History

History
115 lines (80 loc) · 6.28 KB

CONTRIBUTING.adoc

File metadata and controls

115 lines (80 loc) · 6.28 KB
Raw

Contributing to the Asciidoctor Docker Container

Requirements

You need the following tools:

  • A bash compliant command line

  • GNU make

  • Bats installed and in your bash PATH

  • Docker installed and in your PATH

  • Trivy CLI in case you want to scan images for vulnerabilities

How to build and test?

  • Bats is used as a test suite runner. Since the ability to build is one way of testing, it is included.

  • You just have to run the Bats test suite, from the repository root:

    make test

Include test in your build pipeline or test manually

You can use Bats directly to test the image. Optionally, you can specify a custom image name:

# If you want to use a custom name for the image, OPTIONAL
export DOCKER_IMAGE_NAME_TO_TEST=your-image-name
bats tests/*.bats

How to add a dependency?

Adding a dependency/new feature follows this process:

  • An issue is usually recommended to explain the rationale of adding this new dependency with:

    • Describing the feature is helps to provide to end users

    • Evaluating the size of this new dependency is a good thing to help maintainers

    • Links to the added project to help maintainer check and understand the underlying project (licensing, lifecycle, etc.)

  • Then, a pull request mentioning the issue above is required with changes described below

  • If the pull request is approved by the maintainers and merged to the principal branch:

    • An automatic release of the image with the latest tag will be published to the DockerHub in the hour following the pull request merge

    • A new release version of the image will be performed by a maintainers in the next hours or days, and automatically published with the same tag on the DockerHub

The pull request is expecting the following mandatory changes:

  • The dependency is added in the Dockerfile

  • The dependency version must be pinned in different files:

  • One (or many) test case(s) must be added in the Bats Test Harness

  • It is recommended not to update the README.md (Markdown file): there is an automated process expected to take care of this step

Once the pull request is merged, you may produces a second pull request to add an updatecli manifest tracking the version of the newly added dependency. Of course this is not mandatory and should not block your contribution in any ways: maintainers are the expected fallback if you cannot or do not want to produce this second change.

How to bump a dependency?

Dependencies of the image (operating system, packages, Asciidoctor projects, etc.) are tracked using updatecli. Once a day, a GitHub Action workflow updatecli.yaml is executed and opens pull requests if a new dependency can be bumped.

The list of tracked dependencies can be found in https://github.com/asciidoctor/docker-asciidoctor/tree/main/updatecli/updatecli.d. Each YAML file maps to a given dependency and the section targets list each file modified on each version bump.

If you are a maintainer of any of these dependencies and want it to be bumped:

  • Usual process is to wait 24 hours after you’ve released your project: the automatic pull request should be created, and approved/merged/released by maintainers

  • If the update is time-bound, you can either:

    • Open the pull request yourself, by running the following updatecli command on your machine with your own GitHub token:

      export UPDATECLI_GITHUB_TOKEN=xxxxx
updatecli apply --values ./updatecli/values.yaml --config ./updatecli/updatecli.d/<YAML manifest of your dependency>

    • Open the pull request yourself by updating the files manually. The list of files can be found in the related `updatecli``related manifest.

How to scan for vulnerabilities?

  • Trivy scans a docker image looking for software versions containing known vulnerabilities (CVEs). It’s always a good idea to scan the image to ensure no new issues are introduced.

  • Run the following command to replicate the repo’s CVE Scan pipeline on an image build locally. Note the pipeline runs nightly on the latest release version, so it can display issues solved in main branch.

    trivy image --severity HIGH,CRITICAL asciidoctor:latest

Deploy

The goal for deploying is to make the Docker image available with the correct Docker tag in Docker Hub.

As a matter of trust and transparency for the end-users, the image is rebuilt by Docker Hub itself by triggering a build. This only works under the hypothesis of a minimalistic variation between the Docker build in the CI, and the Docker build by Docker Hub.

Deploying the image requires setting the following environment variables: DOCKERHUB_SOURCE_TOKEN and DOCKERHUB_TRIGGER_TOKEN. Their values come from a Docker Hub trigger URL: https://hub.docker.com/api/build/v1/source/${DOCKERHUB_SOURCE_TOKEN}/trigger/${DOCKERHUB_TRIGGER_TOKEN}/call/.

You might want to set these variables as secret values in your CI to avoid any leaking in the output (as curl output for instance).