Account for correlated branches in manually triggered CI builds

[andrewmogan]

Addresses #27. The problem was in how the target and caller branches are inferred:

env:
  CALLER_BRANCH: ${{ github.head_ref || github.ref_name }}
  TARGET_BRANCH: ${{ github.base_ref || github.ref_name }}

github.head_ref and github.base_ref are only defined when the triggering event is a pull request. So, when the workflow is manually triggered, the caller and target branches both fall back to the current branch. In the case of the workflow mentioned in #27, this means both were set to johnfreeman/file_formats_refactor, which in turn means that clone_all_packages_with_branch.py never gets called:

if [[ "$CALLER_BRANCH" == "$TARGET_BRANCH" ]]; then
  cp -pr /ghw/DUNE-DAQ/$REPO .
else   # Someone opened a PR
  export GITHUB_TOKEN=$GITHUB_TOKEN
  /ghw/daq-release/scripts/clone_all_packages_with_branch.py --branch $CALLER_BRANCH --package-group coredaq 
  /ghw/daq-release/scripts/clone_all_packages_with_branch.py --branch $CALLER_BRANCH --package-group fddaq
fi

A solution I landed on is to add an optional input to workflow_dispatch for specifying the target branch:

on:
  workflow_call:
    inputs:
      caller_event_name:
        required: true
        type: string
        description: "Flag to distinguish between e.g. schedule and pull request"
      target_branch:
        type: string
        default: ''
        description: "Branch this change targets (e.g. develop). Affects the release image and whether matching feature branches are cloned. Leave blank to use the current branch."

and then use that branch if specified:

TARGET_BRANCH: ${{ inputs.target_branch || github.base_ref || github.ref_name }}

This means you can run the CI build from feature/my_feature and specify the target as, for example, develop. I left the default argument as empty rather than develop, but I could be convinced either way.

I tested the normal PR behavior here, and tested correlated PRs when manually setting develop as the target branch here. Note that this picked up the branch amogan/dotgithub_issue27 in both daqsystemtest and fddetdataformats.

Note that this also requires modifying the workflow template used by each repo. You can see the implementation in daqsystemtest here.

I also made a very minor change to how the GITHUB_TOKEN secret is specified to better align with modern/best practices.

[jcfreeman2]

Confirmed Andrew's tests; also (somewhat repeating what he did), I created johnfreeman/dotgithub_issue27_nomerge branches in daqsystemtest and appfwk, and:

• Regression tested that if I opened a PR that those two repos would build, DUNE-DAQ/daqsystemtest#357
• Also checked that I could get both those repos to build if I used a does_not_exist target branch and manually actuated the Workflow, https://github.com/DUNE-DAQ/daqsystemtest/actions/runs/37338681571

[andrewmogan]

I copied the workflow template implementation from the previously mentioned daqsystemtest run (i.e., here) into this PR since the two are related.