Automation of Branch Names for a Simple Standard Build Workflow

[dave2wave]

It should be possible to create and use a standard workflow that automatically takes into account the branch name and our convention about the output brand a prototype is here: https://github.com/apache/petri/blob/dfoulks/pelican-gha/.github/workflows/build-pelican.yml

Note that the following part covers the automation of changes on branches:

on:
  push:
    branches: 
      - 'preview/**'
  pull_request:
    branches: 
      - 'preview/**'
  workflow_dispatch:

We might need an excludes.

The other part computes the branch names and should become part of our standard action:

jobs:
  build-pelican:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.inputs.branch || github.head_ref || github.ref }}
      - name: Determine branch name
        id: get_branch
        run: |
          # Get the current branch name
          echo "BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)" >> $GITHUB_ENV
      - name: Branch
        run: |
          echo "Branch: ${{ env.BRANCH_NAME }}"
          if [ "${{ env.BRANCH_NAME }}" == "${{ github.event.repository.default_branch }}" ]; then
            echo "OUTPUT_BRANCH=asf-site" >> $GITHUB_ENV
          else
            echo "OUTPUT_BRANCH=${{ env.BRANCH_NAME }}-staging" >> $GITHUB_ENV
          fi
      - name: Pelican  Build
        uses: apache/infrastructure-actions/pelican@main
        with:
          destination: ${{ env.OUTPUT_BRANCH }}

Making the destination part of the automation means that the pelican action should babe able to need no inputs.

[sebbASF]

Agreed, I was looking at this earlier.

This branch name calculation should either be a separate action or be included in the pelican action - far too error-prone to have this in every workflow, and maintenance would be a nightmare.

This might mean moving the initial checkout into the action.

Generally a preview branch is created from the default branch, so it will pick up the workflow from there.
That means the workflow must also run for the default branch, which it does not appear to at present.

[dave2wave]

The branch name calculation is simple like this:

          # Get the current branch name
          echo "BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)" >> $GITHUB_ENV

So I think the code is very easy now to add to the action. Checkout first but in the default mode the output branch can be easily determined..

[dave2wave]

This branch name calculation should either be a separate action or be included in the pelican action - far too error-prone to have this in every workflow, and maintenance would be a nightmare.

I think this is best as part of the action

This might mean moving the initial checkout into the action.

I think there may be difficulties. The checkout is best in the workflow.

Generally a preview branch is created from the default branch, so it will pick up the workflow from there.
That means the workflow must also run for the default branch, which it does not appear to at present.

In the end the workflow belongs in the default branch. When that branch is added to the workflow should be determined by migration steps.

[sebbASF]

I think this is best as part of the action

Do you mean workflow?

This might mean moving the initial checkout into the action.

I think there may be difficulties. The checkout is best in the workflow.

Please explain what difficulties?

Generally a preview branch is created from the default branch, so it will pick up the workflow from there.
That means the workflow must also run for the default branch, which it does not appear to at present.

In the end the workflow belongs in the default branch. When that branch is added to the workflow should be determined by migration steps.

I don't understand what you mean.

[sebbASF]

AFAICT the following is redundant, because the default ref is the current branch (unless checking out a different repo)
ref: ${{ github.event.inputs.branch || github.head_ref || github.ref }}

I think the only reason why one might want to specify the ref is to ensure that it agrees with the destination for the pelican action, i.e. don't clobber the destination with the output from another branch.

Also current branch name can be obtained more simply in recent git versions using:
git branch --show-current

I think it should be possible to determine the correct destination within the action.
This would use the current branch and the contents of .asf.yaml.
That could be investigated with a temporary action which just does the calculations (and does not attempt to build the site).
It would need to be tested in various scenarios:

• clone default branch as preview
• clone default branch as not preview
• clone other branch
  Possibly others. This would need an external repo for at least some of the tests.