[Bug]: Action variables in PR body

[kdeldycke]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Variables in the form of ${...}, like ${SOURCE_REPO_PATH} or ${TEMPLATE_GIT_HASH} are not replaced by their values in the PR's body.

Expected Behavior

Based on the default value of the pr_body parameter of the action, which reference ${SOURCE_REPO_PATH} and ${TEMPLATE_GIT_HASH}, I expect these same variable to be replaced by their values.

Current Behavior

In my reuseable workflow, I have a job using actions-template-sync with a pr_body parameter defined as such:

          pr_body: >
            Files synced from [`${SOURCE_REPO_PATH}@${TEMPLATE_GIT_HASH}`
            repository](https://github.com/${SOURCE_REPO_PATH}/tree/${TEMPLATE_GIT_HASH}).


            <details><summary><code>Workflow metadata</code></summary>


            > [Auto-generated on run `#${{ github.run_id }}`](${{ github.event.repository.html_url }}/actions/runs/${{
            github.run_id }}) by `${{ github.job }}` job from [`docs.yaml`](${{ github.event.repository.html_url
            }}/blob/${{ github.sha }}/.github/workflows/docs.yaml) workflow.


            </details>

The body of the resulting PR looks like this:

Its markdown is:

Files synced from [`${SOURCE_REPO_PATH}@${TEMPLATE_GIT_HASH}` repository](https://github.com/${SOURCE_REPO_PATH}/tree/${TEMPLATE_GIT_HASH}).

<details><summary><code>Workflow metadata</code></summary>

> [Auto-generated on run `#8329511778`](https://github.com/kdeldycke/awesome-falsehood/actions/runs/8329511778) by `awesome-template-sync` job from [`docs.yaml`](https://github.com/kdeldycke/awesome-falsehood/blob/8f5877a9bf299e33249d5c681c1010a2cfd467b4/.github/workflows/docs.yaml) workflow.

</details>

Here you can see that ${{ ... }} variables are replaced by their values but the ${...} are not.

Possible Solution

Maybe I am wrong and I cannot reuse the ${SOMETHING} format. So I tried an alternative and replaced them by ${{ env.SOMETHING }} but they reference an empty value, as the env is not populated by these variables.

Maybe we should let the action populate the local env with its own variables so ${{ env.SOMETHING }} will work? Not sure how natural this syntax looks like and how much reusing the env object is bullet-proof.

Additional Information/Context

This is a follow up of #477

Note that the ${...}/${{ ... }} syntax difference has already been encounter and discussed a bit in another issue.

Template sync version Version

2.0.0

[AndreasAugustin]

Hi @kdeldycke nice find.
#508 will fix the issue (v2.0.1).

One remark:
Just one change to the request.
SOURCE_REPO is the variable which will be substituted. SOURCE_REPO_PATH is an unchanged input variable. You can already use that one in clear text. The source repo is the full url to the repository. (https://<domain>/<source_repo_path>)

Further remark
I do not understand why it did not work. Super weird. theoretically it should have worked 🥷 with variables. Also using this e.g. in case for the hooks.
(My guess are some escape characters, but not sure why it is working e.g. for hooks)
But the change is at least fixing the issue. Am now doing manually the substitution.

[kdeldycke]

Thanks @AndreasAugustin for the 2.0.1 release.

Just tried that and change SOURCE_REPO_PATH to SOURCE_REPO. See: kdeldycke/workflows@a1be500

But I had the following issue:

  To https://github.com/kdeldycke/awesome-falsehood
   ! [remote rejected] sync-awesome-template_8313c9b -> sync-awesome-template_8313c9b (refusing to allow a GitHub App to create or update workflow `.github/workflows/autofix.yaml` without `workflows` permission)
  error: failed to push some refs to 'https://github.com/kdeldycke/awesome-falsehood'

See the details at: https://github.com/kdeldycke/awesome-falsehood/actions/runs/8341154880/job/22826633975#step:3:151

That's kind of strange as I always used a specific token with workflow permissions (as documented here: https://github.com/kdeldycke/workflows?tab=readme-ov-file#permissions-and-token).

Can you spot anything strange in the execution logs of the action? Remember that I'm using it as a reuseable workflow so some subtleties might have influenced the process.

[AndreasAugustin]

Thanks @AndreasAugustin for the 2.0.1 release.

Just tried that and change SOURCE_REPO_PATH to SOURCE_REPO. See: kdeldycke/workflows@a1be500

But I had the following issue:

  To https://github.com/kdeldycke/awesome-falsehood
   ! [remote rejected] sync-awesome-template_8313c9b -> sync-awesome-template_8313c9b (refusing to allow a GitHub App to create or update workflow `.github/workflows/autofix.yaml` without `workflows` permission)
  error: failed to push some refs to 'https://github.com/kdeldycke/awesome-falsehood'

See the details at: https://github.com/kdeldycke/awesome-falsehood/actions/runs/8341154880/job/22826633975#step:3:151

That's kind of strange as I always used a specific token with workflow permissions (as documented here: https://github.com/kdeldycke/workflows?tab=readme-ov-file#permissions-and-token).

Can you spot anything strange in the execution logs of the action? Remember that I'm using it as a reuseable workflow so some subtleties might have influenced the process.

Hi @kdeldycke
You are using a workflow_call. Therefore AFAIK you need to inject the secrets. Like https://github.com/AndreasAugustin/actions-template-sync/blob/main/.github/workflows/release.yml
Line 15

Seems you are currently not using your PAT and instead the GitHub secret. Hope the current idea helps. Am on mobile and it is hard to type and search for links/type examples. https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow

Update had a closer look and my guess is that the statement above is right. Here some more details/thoughts:
assuming you are defining the secret WORKFLOW_UPDATE_GITHUB_PAT within your workflow file you need to define e.g. secrets: inherit (or the other option mentioned in https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow) or else the secret will be empty within the called workflow and the default GITHUB_TOKEN is used.

docs:
  uses: kdeldycke/workflows/.github/workflows/docs.yaml@v3.4.1
  # add this line
  secrets: inherit

[AndreasAugustin]

@kdeldycke I wrote a small test to verify my theory. Please check the workflow file here https://github.com/AndreasAugustin/sync-test/blob/main/.github/workflows/outer_call.yml
the called workflow is in the same repository
https://github.com/AndreasAugustin/sync-test/blob/main/.github/workflows/sync.yml

without the secrets: inherit like mentioned above I get an error about missing github_token. You have a fallback defined in your case so the fallback will take place.

So I am kinda sure you are using the fallback instead of the PAT

Also within the git init log part (expand) in your action run https://github.com/kdeldycke/awesome-falsehood/actions/runs/8341154880/job/22826633975#step:3:151
you can see the prefix of the token which is related to the action GITHUB_TOKEN and not a gh_pat

[AndreasAugustin]

@kdeldycke did you have the chance to test the suggestion with secrets: inherit?

Further info: #478 (#516) is now (finally) released with v2.1.0.
Thanks for your patience.

(Sorry for hijacking this issue ticket)

[kdeldycke]

So I am kinda sure you are using the fallback instead of the PAT

Yes, it looks that it is the case. The question is why?

Also within the git init log part (expand) in your action run https://github.com/kdeldycke/awesome-falsehood/actions/runs/8341154880/job/22826633975#step:3:151 you can see the prefix of the token which is related to the action GITHUB_TOKEN and not a gh_pat

Yep, that's the definitive proof the workflow is falling back on the local GITHUB_TOKEN secret.

So... I updated to latest v2.1.0 and added the secrets: inherit parameter on the calling workflow: https://github.com/kdeldycke/awesome-falsehood/blob/6d629bd5876e6af7cb00f6ec9adfd941ad0ecdba/.github/workflows/docs.yaml#L12-L14

And it works: https://github.com/kdeldycke/awesome-falsehood/actions/runs/8844290657/job/24285909296#step:3:146

Thanks @AndreasAugustin for the help!

Still, I don't understand why my custom WORKFLOW_UPDATE_GITHUB_PAT is not picked up. As it was properly available on the local, calling repository since the beginning:

🤔

My guts tells me its because I'm too deep in the inception: I use reuseable workflow to update workflows from the repository implementing the reuseable workflows! 😵‍💫

[AndreasAugustin]

Still, I don't understand why my custom WORKFLOW_UPDATE_GITHUB_PAT is not picked up. As it was properly available on the local, calling repository since the beginning

@kdeldycke
My guess:
if you reuse a workflow you must add the secrets you use into the reusable workflow and explicitly list them within the caller workflow OR use the secrets: inherit part. Else the secret is not set within the reusable workflow.
https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow

Thats somehow different between reusable workflows or writing an action.

[kdeldycke]

Still, I don't understand why my custom WORKFLOW_UPDATE_GITHUB_PAT is not picked up. As it was properly available on the local, calling repository since the beginning

@kdeldycke My guess: if you reuse a workflow you must add the secrets you use into the reusable workflow and explicitly list them within the caller workflow OR use the secrets: inherit part. Else the secret is not set within the reusable workflow. https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow

Thats somehow different between reusable workflows or writing an action.

Yes, something like that. But it was my understanding that my strategy was already working as it is not the first time I refer to local secrets. Anyway, I'll continue testing my hypothesis. Thanks @AndreasAugustin for taking the time trying to solve this mystery! 🤗