Call the Homebrew bump from the release instead of an event trigger - #400

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- workflow files ---'
git ls-files '.github/workflows/*' | sort

printf '%s\n' '--- homebrew-bump.yml ---'
cat -n .github/workflows/homebrew-bump.yml

printf '%s\n' '--- release.yml relevant section ---'
cat -n .github/workflows/release.yml | sed -n '175,205p'

printf '%s\n' '--- references ---'
rg -n --hidden --glob '.github/workflows/**' 'HOMEBREW_BUMP_ACCESS_TOKEN|uses:.*homebrew-bump|workflow_call|workflow_dispatch|secrets:' .

Repository: XCTestHTMLReport/XCTestHTMLReport

Length of output: 3930

🏁 Script executed:

#!/bin/bash
set -eu

cat -n .github/workflows/homebrew-bump.yml
printf '\n--- release caller ---\n'
cat -n .github/workflows/release.yml | sed -n '175,205p'
printf '\n--- references ---\n'
rg -n --hidden --glob '.github/workflows/**' \
  'HOMEBREW_BUMP_ACCESS_TOKEN|homebrew-bump|workflow_call|workflow_dispatch|secrets:' .

Repository: XCTestHTMLReport/XCTestHTMLReport

Length of output: 3656

🌐 Web query:

GitHub Actions reusable workflow undeclared secrets context workflow_call direct workflow_dispatch secrets expression

💡 Result:

In GitHub Actions, secrets are not automatically available to reusable workflows due to security boundaries [1]. To use secrets within a reusable workflow, they must be explicitly handled using one of the following methods: 1. Explicit Passing: You can explicitly pass secrets from the caller workflow to the called workflow using the secrets keyword within the job definition [2][3]. The reusable workflow must define these secrets in its on.workflow_call.secrets configuration [2][4]. 2. Inherit: You can use the secrets: inherit keyword in the caller workflow [3][5]. This automatically passes all secrets available to the caller to the reusable workflow [1][5]. Even when using inherit, the reusable workflow should still declare the secrets it expects to consume under on.workflow_call.secrets, though setting required: false is sufficient [1][4]. Regarding workflow_dispatch and workflow_call: A single workflow file can be triggered by both workflow_call and workflow_dispatch [6]. However, when a workflow is triggered via workflow_dispatch, it does not receive secrets through the same mechanism as a reusable workflow call [6]. When you manually trigger a workflow that also supports workflow_call, it operates under the context of the workflow_dispatch event, and you cannot "pass" secrets to it as you would from a caller workflow [6][7]. If your workflow relies on secrets, you must ensure those secrets are available in the repository settings, and they will be accessed directly by the workflow steps [6]. Important considerations: - Context Availability: The secrets context is not available at the job-level with: block [8]. You cannot pass a secret value into an input variable using ${{ secrets.SECRET_NAME }} because the with: block is evaluated at parse time before secrets are resolved [8]. To handle this, pass the secret name as a string via inputs and resolve the secret dynamically inside the called workflow using the syntax ${{ secrets[inputs.secret_name] }} [8]. - Undefined Secrets: If you attempt to pass a secret that is not declared in the called workflow's on.workflow_call.secrets (and you are not using secrets: inherit), the workflow will fail at the parsing stage with an error indicating the secret is not defined [4]. - Environment Secrets: Reusable workflows do not support passing environment secrets via the caller's secrets block [3]. If a reusable workflow specifies an environment, it will use that environment's secrets rather than any secrets passed from the caller [3]. Top results: [2][6][1][8][4]

Citations:

• 1: https://fixdevs.com/blog/github-actions-reusable-workflow/
• 2: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
• 3: https://docs.github.com/en/[email protected]/actions/using-workflows/reusing-workflows
• 4: https://latchkey.dev/learn/github-actions/gha-reusable-secret-not-defined-called-in-ci
• 5: https://pipelinesandpizza.com/posts/git/github-actions-reusable-workflows/
• 6: https://stackoverflow.com/questions/75744243/can-i-dispatch-a-github-reusable-workflow-that-uses-secrets
• 7: workflow_call github context is not updated. actions/runner#1548
• 8: https://dev.to/cseeman/why-your-github-actions-secrets-dont-work-in-reusable-workflow-inputs-462g

🏁 Script executed:

#!/bin/bash
set -eu

if command -v actionlint >/dev/null 2>&1; then
  actionlint .github/workflows/homebrew-bump.yml .github/workflows/release.yml
else
  echo "actionlint is not installed"
fi

printf '\n--- workflow_call secret declarations and references ---\n'
rg -n -C 3 'workflow_call|secrets:|secrets\.[A-Za-z_][A-Za-z0-9_]*' \
  .github/workflows/homebrew-bump.yml .github/workflows/release.yml

Repository: XCTestHTMLReport/XCTestHTMLReport

Length of output: 551

🌐 Web query:

site:docs.github.com/en/actions reusable workflow secrets context undeclared secret reference called workflow

💡 Result:

In GitHub Actions, secrets are not automatically inherited by reusable workflows [1][2]. If a reusable workflow attempts to access a secret that has not been explicitly defined and passed by the caller, the workflow run will fail [3][4]. When you encounter an error regarding an undeclared secret reference in a called workflow, it is because of the following requirements: 1. Define in the Called Workflow: You must declare the secret in the reusable workflow's on.workflow_call section [3][4]. This identifies which secrets the reusable workflow expects to receive [3][4]. Example: on: workflow_call: secrets: REQUIRED_SECRET: description: 'A secret passed from the caller' required: true 2. Pass from the Caller Workflow: The caller workflow must then map a secret from its own context to the secret defined in the called workflow using the secrets keyword within the job configuration [1][3]. Example: jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main secrets: REQUIRED_SECRET: ${{ secrets.MY_SECRET }} Alternatively, you can use secrets: inherit in the caller workflow to pass all secrets from the caller to the called workflow automatically [1]. If a caller workflow passes a secret that is not defined in the called workflow, it results in an error [3][4]. If you are passing secrets to a nested reusable workflow, you must explicitly pass them at every level of the workflow chain [1][3].

Citations:

• 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
• 2: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
• 3: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
• 4: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax?use_case=

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.