publish-build-metadata

Internal Babbel tool to collect build artifacts metadata.

Usage

In your project workflow, after build artifact was published.

All AWS_ secrets should be already set and ready to use.

Standalone project example

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    #
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}

Microverse example, all slices at once

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    #
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}
          slices: 'api, consumer.kinesis, consumer.firehose'

Microverse example, one slice at a time

For example in case you have jobs matrix.

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    #
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}
          slices: 'api' # or ${{ matrix.function_name }}

When custom Commit SHA

Sometimes you might trigger an automatic build which fetches a different branch. In such case GITHUB_SHA differs from actual Commit SHA that the build is working on.

In such case you can override GITHUB_SHA by passing extra parameter:

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    #
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}
          sha: ${{ env.MY_CUSTOM_COMMIT_SHA }}

Usually with above it will be handy to be able to specify the branch name as well, so the full example would look like:

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    #
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}
          sha: ${{ env.MY_CUSTOM_COMMIT_SHA }}
          branch: ${{ env.MY_CUSTOM_BRANCH }}

Pull-Request triggered workflows

For PR-triggered workflows, the branch (GITHUB_REF) and commit (GITHUB_SHA) which will be deployed by default are the PR merge branch and its last merge commit respectively. This merge branch and commit are auto-generated by Github.

For more details, see this thread. Also, here's a great article on the behaviour of push vs pull-request triggered workflows.

In the Deploy App, PR-triggered workflows can be identified by:

• Branch names in the format: refs/pull/<PR number>/merge e.g refs/pull/123/merge
• Commit messages in the following format: Merge 51a13eb7fad0401d4ef5d01a98c729c7e231fe8e into 912858b8fb3fc0318a892b1b7e69ee72592717bb (388611d).

where:

• 51a13eb... is the head commit on your feature branch,
• 912858b... is the head commit on the main branch and
• 388611d... is the PR merge commit auto-generated by Github.

To display a more meaningful commit message in the Deploy App, a commit_message_sha input may be provided. The publish-build-metadata action will pass the commit message corresponding to the provided commit_message_sha to the Deploy App.

NB: This commit_message_sha input is purely for display purposes in the Deploy App. The commit which will be deployed remains the GITHUB_SHA commit on the GITHUB_REF branch. This may cause some confusion, so keep this in mind when using it.

permissions:
  contents: read
  id-token: write

jobs:
  name_of_the_job:
    # ...
    #
    steps:
      # NB: actions/checkout fetches only a `single` commit by default.
      # For PR-triggered workflows, this will be the PR merge commit auto-generated by Github.
      # Set `fetch-depth` to (at least) 2 so it also fetches the head commit on your feature branch.
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 2
    # ...
    #
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
      #
      # ... build & publish the artifact
      #
      - uses: babbel/publish-build-metadata@v1
        with:
          meta_table_arn: ${{ vars.AWS_META_TABLE_ARN }}
          commit_message_sha: ${{ github.event.pull_request.head.sha || github.sha }}

In the sample above, github.event.pull_request.head.sha refers to the head commit on your feature branch.

If it is not a PR-triggered workflow (e.g the workflow is triggered on push), then github.event.pull_request.head.sha will be absent from the Github context, so it will fall back to github.sha.

NB: If you don't pass fetch-depth: 2 to actions/checkout, your CI run will fail with: Error: The process '/usr/bin/git' failed with exit code 128.

Contribute

Prep the project, it runs against nodejs v20, when using asdf-vm just hit asdf install. Then install the packages

npm ci

Run the tests

make test

Or better run the whole build all the time, this way you won't forget to run it before commit

make build