Reusable GitHub Actions workflows

build-reusable.yaml

This workflow:

  • Compiles using the specified Java compiler version

Examples

Snippet from an example build.yaml using this workflow
build:
  uses: apache/logging-parent/.github/workflows/build-reusable.yaml@gha/v0
  secrets:
    DV_ACCESS_TOKEN: ${{ startsWith(github.ref_name, 'release/') && '' || secrets.DEVELOCITY_ACCESS_KEY }}
  with:
    site-enabled: true
    reproducibility-check-enabled: false
    develocity-enabled: ${{ ! startsWith(github.ref_name, 'release/') }}

deploy-snapshot-reusable.yaml

This workflow deploys SNAPSHOT artifacts.

Examples

Snippet from an example build.yaml using this workflow
deploy-snapshot:
  needs: build
  if: github.repository == 'apache/logging-log4j2' && github.ref_name == '2.x'
  uses: apache/logging-parent/.github/workflows/deploy-snapshot-reusable.yaml@gha/v0
  # Secrets for deployments
  secrets:
    NEXUS_USERNAME: ${{ secrets.NEXUS_USER }}
    NEXUS_PASSWORD: ${{ secrets.NEXUS_PW }}

deploy-release-reusable.yaml

This workflow:

  • Deploys release artifacts

  • Updates revision and project.build.outputTimestamp Maven properties

  • Generates the distribution ZIP containing Git-tracked sources, binary attachments, NOTICE.txt, etc.

  • Generates the release vote & announcement emails

  • Uploads the distribution ZIP and emails to SVN

Examples

Snippet from an example build.yaml using this workflow
deploy-release:
  needs: build
  if: github.repository == 'apache/logging-log4j2' && startsWith(github.ref_name, 'release/')
  uses: apache/logging-parent/.github/workflows/deploy-release-reusable.yaml@gha/v0
  # Secrets for deployments
  secrets:
    GPG_SECRET_KEY: ${{ secrets.LOGGING_GPG_SECRET_KEY }}
    NEXUS_USERNAME: ${{ secrets.LOGGING_STAGE_DEPLOYER_USER }}
    NEXUS_PASSWORD: ${{ secrets.LOGGING_STAGE_DEPLOYER_PW }}
    SVN_USERNAME: ${{ secrets.LOGGING_SVN_DEV_USERNAME }}
    SVN_PASSWORD: ${{ secrets.LOGGING_SVN_DEV_PASSWORD }}
  # Write permissions to allow the Maven `revision` property update, changelog release, etc.
  permissions:
    contents: write
  with:
    project-id: log4j

verify-reproducibility-reusable.yaml

This workflow verifies the reproducibility of a previous deploy-snapshot-reusable.yaml or deploy-release-reusable.yaml workflow.

Examples

To verify the reproducibility of a snapshot, you can use:

Snippet from an example build.yaml using this workflow
verify-reproducibility-snapshot:
  needs: deploy-snapshot
  name: "verify-reproducibility (${{ needs.deploy-snapshot.outputs.project-version }})"
  uses: apache/logging-parent/.github/workflows/verify-reproducibility-reusable.yaml@gha/v0
  with:
    # Reference repository
    nexus-url: https://repository.apache.org/content/groups/snapshots
    # Encode the `runs-on` input as JSON array
    runs-on: '["ubuntu-latest", "macos-latest"]'

To verify the reproducibility of a release, you can use:

Snippet from an example build.yaml using this workflow
verify-reproducibility-release:
  needs: deploy-release
  name: "verify-reproducibility (${{ needs.deploy-release.outputs.project-version }})"
  uses: apache/logging-parent/.github/workflows/verify-reproducibility-reusable.yaml@gha/v0
  with:
    # Reference repository
    nexus-url: ${{ needs.deploy-release.outputs.nexus-url }}
    # Encode the `runs-on` input as JSON array
    runs-on: '["ubuntu-latest", "macos-latest"]'

analyze-dependabot-reusable.yaml

Analyzes Dependabot pull requests to collect detailed information about updated dependencies. Stores the results in the dependabot-metadata artifact, which is later consumed by the process-dependabot-reusable.yaml workflow to automate changelog generation and PR processing.

This workflow must be triggered by an event that includes the pull_request payload and does not require any privileges. It can then be used in a pull_request workflow.
Snippet from an example analyze-dependabot.yaml using this workflow
analyze-dependabot:
  # `github.actor` prevents recursive calls when `github-actions[bot]` pushes to the PR;
  # `github.event.pull_request.user.login` skips PRs not opened by Dependabot.
  if: ${{
      github.repository == 'apache/logging-parent'
      && github.actor == 'dependabot[bot]'
      && github.event.pull_request.user.login == 'dependabot[bot]'
    }}
  uses: apache/logging-parent/.github/workflows/analyze-dependabot-reusable.yaml@gha/v0

process-dependabot-reusable.yaml

Helps to process Dependabot pull requests by:

  • Generating changelog entries for the updated dependencies.

  • Enabling the "auto-merge" option for the pull request.

The workflow needs the following privileged tokens:

GITHUB_TOKEN

The default GitHub token with contents:write and pull-requests: write permissions, used to enable auto-merge on pull requests.

This token is automatically provided by GitHub Actions, but needs to be configured in the permissions property.

RECURSIVE_TOKEN

A GitHub token required to push generated changelog files as a new commit to the repository. The default GITHUB_TOKEN can not be used, as it will not trigger required check runs and will prevent the pull request from being merged. A Personal Access Token (PAT) with contents:write permission must be provided instead.

The token must be passed as a secret named RECURSIVE_TOKEN.

This workflow is designed to be triggered by the workflow_run event, as soon as the analyze-dependabot-reusable.yaml workflow completes.

When this workflow is triggered by workflow_run, GitHub Actions uses the "Actions" secret context instead of "Dependabot" secrets, even if the github.actor is dependabot[bot].
Snippet from an example process-dependabot.yaml using this workflow
process-dependabot:
  # Skip this workflow on commits not pushed by Dependabot
  if: ${{
      github.repository == 'apache/logging-parent'
      && github.actor == 'dependabot[bot]'
      && github.event.workflow_run.conclusion == 'success'
    }}
  uses: apache/logging-parent/.github/workflows/process-dependabot-reusable.yaml@gha/v0
  permissions:
    # The default GITHUB_TOKEN will be used to enable the "auto-merge" on the PR
    # This requires the following two permissions:
    contents: write
    pull-requests: write
  secrets:
    RECURSIVE_TOKEN: ${{ secrets.DEPENDABOT_TOKEN }}
  with:
    # The path to the changelog directory for the current development branch.
    changelog-path: src/changelog/.2.x.x

deploy-site-reusable.yaml

This workflow builds and deploys the website.

Examples

To update the staging website, you can use:

Snippet from an example deploy-site.yaml using this workflow
deploy-site-stg:
  if: github.repository == 'apache/logging-log4j2' && github.ref_name == '2.x'
  uses: apache/logging-parent/.github/workflows/deploy-site-reusable.yaml@gha/v0
  # Secrets for committing the generated site
  secrets:
    GPG_SECRET_KEY: ${{ secrets.LOGGING_GPG_SECRET_KEY }}
  # Write permissions for committing the generated site
  permissions:
    contents: write
  with:
    asf-yaml-content: |
      staging:
        profile: ~
        whoami: ${{ github.ref_name }}-site-stg-out
        subdir: content/log4j/2.x
    install-required: true
    target-branch: ${{ github.ref_name }}-site-stg-out

To stage a separate website for a release candidate, you can use:

Snippet from an example deploy-site.yaml using this workflow
export-version:
  if: github.repository == 'apache/logging-log4j2' && startsWith(github.ref_name, 'release/')
  runs-on: ubuntu-latest
  outputs:
    version: ${{ steps.export-version.outputs.version }}
  steps:
    - name: Export version
      id: export-version
      run: |
        version=$(echo "${{ github.ref_name }}" | sed 's/^release\///')
        echo "version=$version" >> "$GITHUB_OUTPUT"

deploy-site-rel:
  needs: export-version
  uses: apache/logging-parent/.github/workflows/deploy-site-reusable.yaml@gha/v0
  # Secrets for committing the generated site
  secrets:
    GPG_SECRET_KEY: ${{ secrets.LOGGING_GPG_SECRET_KEY }}
  # Write permissions for committing the generated site
  permissions:
    contents: write
  with:
    asf-yaml-content: |
      staging:
        profile: ~
        whoami: ${{ github.ref_name }}-site-stg-out
        subdir: content/log4j/${{ needs.export-version.outputs.version }}
    install-required: true
    target-branch: ${{ github.ref_name }}-site-stg-out

To update the production website after a release, you can use:

Snippet from an example deploy-site.yaml using this workflow
deploy-site-pro:
  if: github.repository == 'apache/logging-log4j2' && github.ref_name == '2.x-site-pro'
  uses: apache/logging-parent/.github/workflows/deploy-site-reusable.yaml@gha/v0
  # Secrets for committing the generated site
  secrets:
    GPG_SECRET_KEY: ${{ secrets.LOGGING_GPG_SECRET_KEY }}
  # Write permissions for committing the generated site
  permissions:
    contents: write
  with:
    asf-yaml-content: |
      publish:
        whoami: ${{ github.ref_name }}-out
        subdir: content/log4j/2.x
    install-required: true
    target-branch: ${{ github.ref_name }}-out