https://github.com/babbel/publish-build-metadata

Collects build artifacts metadata and publishes them to DynamoDB
https://github.com/babbel/publish-build-metadata

actions

Last synced: about 2 months ago
JSON representation

Collects build artifacts metadata and publishes them to DynamoDB

• Host: GitHub
• URL: https://github.com/babbel/publish-build-metadata
• Owner: babbel
• License: mit
• Created: 2021-05-06T10:11:02.000Z (about 5 years ago)
• Default Branch: main
• Last Pushed: 2024-04-22T10:52:12.000Z (about 2 years ago)
• Last Synced: 2024-04-22T12:02:30.362Z (about 2 years ago)
• Topics: actions
• Language: JavaScript
• Homepage:
• Size: 2.05 MB
• Stars: 1
• Watchers: 39
• Forks: 0
• Open Issues: 6
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • License: LICENSE
  • Codeowners: .github/CODEOWNERS

Awesome Lists containing this project

README

          
# 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

```yaml

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

```yaml

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.

```yaml

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:

```yaml

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:

```yaml

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](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request), 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](https://github.com/orgs/community/discussions/26325). Also, here's a great [article](https://medium.com/@lizjohnson_83228/the-difference-between-push-and-pull-request-triggers-in-github-d7c0f2bc19db) 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//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.**

```yaml

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

      # ...

      - 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

```