Skip to content

Latest commit

 

History

History
72 lines (51 loc) · 2.1 KB

03-maintainer-guide.adoc

File metadata and controls

72 lines (51 loc) · 2.1 KB
Raw

Maintainer Guide

Table of Contents

Audience

You are a maintainer of this project.

Publishing a New Release

Is invoked from the command line via:

bb publish

It validates:

  • local git

    • you are on master branch

    • do not have any uncommitted code

    • do not have any unpushed commits

  • changelog

    • Has an "Unreleased" section with content

Then locally:

  1. bumps the version <release count> (our scheme is major.minor.<release count>)

    • Our version is stored in deps.edn under :aliases :neil :project :version

  2. applies version to:

    1. doc/01-user-guide.adoc

    2. CHANGELOG.adoc

  3. git commits: deps.edn doc/01-user-guide.adoc CHANGELOG.adoc

  4. git tags with release tag v<version>

  5. pushes commit

  6. pushes tag

Then up on CI, the CI publish workflow is only triggered when it sees a release tag:

  1. CI tests workflow is invoked

  2. a release jar is published to clojars

  3. a GitHub release is created

  4. cljdoc is informed of the new release

Tip
 you can run just the publish validations alone via bb pubcheck

Relevant Sources

Scripts:

  1. bb.edn - tasks entry point

  2. script/publish.clj - client side work

  3. script/ci_publish.clj - ci side work

CI - We use GitHub Actions for this project

  1. .github/workflows/tests.yml

  2. .github/workflows/publish.yml

CI Config

Clojars secrets are protected under the publish environment which is only referenced by publish.yml.

The nvd api token is stored under the nvd environment and refernced by nvd_scanner.yml. Should you need to update the token, you can request one here: https://nvd.nist.gov/developers/request-an-api-key. If you are using gmail, you can request a unique token for clj-yaml CI by including +clj-yaml in your email address, ex. bob@gmail.com becomes bob+clj-yaml@gmail.com.

Expected Oddities

When publishing, you will see both the tests workflow triggered and the publish workflow triggered (which also invokes the tests workflow).

This extra running of the tests workflow is GitHub Actions responding to changes committed as part of the publishing work. A bit annoying, but harmless.