fix: add necessary permissions to example workflow #31582

corneliusroemer · 2024-02-12T15:44:32Z

Why:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Uses the diff from #31322
but adds explicit permissions as well
which allows it to be tested with
workflow_dispatch: if users desire so

Also use github.ref_name instead of the pull_request.number to query the branch
I couldn't get the original to work in local tests
but with ref_name it works flawlessly.

Check off the following:

I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).
- For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.
For content changes, I have completed the self-review checklist.

Uses the diff from github#31322 but adds explicit permissions as well which allows it to be tested with `workflow_dispatch:` if users desire so Also use `github.ref_name` instead of the pull_request.number to query the branch I couldn't get the original to work in local tests but with `ref_name` it works flawlessly.

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

…up-workflows.md

github-actions · 2024-02-12T15:50:42Z

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
`actions/using-workflows/caching-dependencies-to-speed-up-workflows.md`	fpt ghec ghes@ 3.11 3.10 3.9 3.8	fpt ghec ghes@ 3.11 3.10 3.9 3.8

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server

Mogyuchi · 2024-02-12T17:43:54Z

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

@@ -369,7 +371,7 @@ jobs:
        env:
          GH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
          REPO: {% raw %}${{ github.repository }}{% endraw %}
-          BRANCH: refs/pull/{% raw %}${{ github.event.pull_request.number }}{% endraw %}/merge
+          BRANCH: {% raw %}${{ github.ref_name }}{% endraw %}


Indeed, using ref_name in workflow_dispatch is the correct approach.

However, this approach is not correct in this example.
Because, the cache is created for the merge ref (refs/pull/.../merge) when a cache is created by a workflow run triggered on a pull request. Therefore, it will not work correctly with ref_name.

I think I might have been wrong - ref_name ends up being main/master after merge. We'd need github.head_ref here instead.

nguyenalex836 · 2024-02-12T17:51:14Z

@corneliusroemer Thanks so much for opening a PR! I'll get this triaged for review ✨

corneliusroemer · 2024-02-12T18:06:11Z

@Mogyuchi made a good point that github.ref_name might not be the right name here, instead one should probably use github.head_ref.

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

…up-workflows.md

Mogyuchi · 2024-02-12T19:08:29Z

@Mogyuchi made a good point that github.ref_name might not be the right name here, instead one should probably use github.head_ref.

@corneliusroemer
Sorry, I should have just said it straight.
In short, to clear the cache for a pull request, we need to stick to refs/pull/${{ github.event.pull_request.number }}/merge. Alternatively, if we want to clear the branch cache as well, we need to do it like discordjs-japan/om # 90 (pull_request should be replaced by pull_request_target).

Mogyuchi · 2024-02-12T18:29:37Z

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

    types:
      - closed

 jobs:
  cleanup:
    runs-on: ubuntu-latest
+    permissions:
+      actions: write


permissions is required regardless of the event if "Read and write permissions" are not selected in the settings(Settings > Actions > General > Actions permissions > Workflow permissions). In other words, it is not relevant to changing pull_request_target.
Therefore, I believe it is more appropriate to make this a separate pull request from #31322 .

Mogyuchi · 2024-02-12T22:58:11Z

…I feel like I need to explain how what is written in restrictions-for-accessing-a-cache affects cache cleanup.
Simply put, for example, if you have a pull request 123 with head(current) branch feature-b, the cache created by the push event will be for feature-b and the cache created by the pull_request event will be for refs/pull/123 /merge.
So, if the cache you want to delete was created in the push event, you need to specify the cache for feature-b, and if it was created in the pull_request event, you need to specify refs/pull/123/merge.

jc-clark · 2024-03-05T22:44:35Z

Hello @corneliusroemer and @Mogyuchi - thank you for the suggestions here. We had a chance to dig into this on our team and we agreed that we shouldn't change this example to use pull_request_target vs pull_request. The majority of our docs readers will be using the pull_request trigger and using this as the default aligns with the rest of our documentation as well.

That said, I didn't want to outright close this PR because I think it's a valid change to cover the cross-repository pull request use case.

In the "Events that trigger workflows" article, we do have a warning box about the permissions: "pull_request_target"

Which looks like it has the context someone would need for the cross-repo pull requests.

A few questions for you:

What would you think of keeping pull_request as the triggering event here but adding a note above the example that links to "pull_request_target" and describes the cross-repo pull request use case?
Based on this comment, it sounds like we should keep the permissions lines in this example even if we just use pull_request. Does that sound right?
Should this line remain the same: BRANCH: refs/pull/{% raw %}${{ github.event.pull_request.number }}{% endraw %}/merge

Mogyuchi · 2024-03-07T07:19:02Z

@jc-clark

#31582 (comment)

Therefore, I believe it is more appropriate to make this a separate pull request from #31322 .

What I wanted to say is that I don't want this pull request to be based on my pull request.

What would you think of keeping pull_request as the triggering event here but adding a note above the example that links to "pull_request_target" and describes the cross-repo pull request use case?

I think we should talk about this in #31322, so I'll answer there.

Based on #31582 (comment), it sounds like we should keep the permissions lines in this example even if we just use pull_request. Does that sound right?

Yes. We should specify the permission. https://securitylab.github.com/research/github-actions-building-blocks/#following-the-principle-of-least-privilege

Should this line remain the same: BRANCH: refs/pull/{% raw %}${{ github.event.pull_request.number }}{% endraw %}/merge

Yes. Related pull request: #23612

corneliusroemer had a problem deploying to preview-env-31582 February 12, 2024 15:44 — with GitHub Actions Error

github-actions bot added the triage Do not begin working on this issue until triaged by the team label Feb 12, 2024

corneliusroemer commented Feb 12, 2024

View reviewed changes

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md Outdated Show resolved Hide resolved

Update content/actions/using-workflows/caching-dependencies-to-speed-…

e92787b

…up-workflows.md

corneliusroemer temporarily deployed to preview-env-31582 February 12, 2024 15:45 — with GitHub Actions Inactive

corneliusroemer mentioned this pull request Feb 12, 2024

Fix cleanup example to use pull_request_target trigger #31322

Open

2 tasks

Mogyuchi reviewed Feb 12, 2024

View reviewed changes

corneliusroemer commented Feb 12, 2024

View reviewed changes

content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md Outdated Show resolved Hide resolved

Update content/actions/using-workflows/caching-dependencies-to-speed-…

48e5a20

…up-workflows.md

corneliusroemer deployed to preview-env-31582 February 12, 2024 18:07 — with GitHub Actions View deployment

Mogyuchi reviewed Feb 12, 2024

View reviewed changes

This comment was marked as spam.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: add necessary permissions to example workflow #31582

fix: add necessary permissions to example workflow #31582

corneliusroemer commented Feb 12, 2024 •

edited

github-actions bot commented Feb 12, 2024 •

edited

Mogyuchi Feb 12, 2024

corneliusroemer Feb 12, 2024

nguyenalex836 commented Feb 12, 2024

corneliusroemer commented Feb 12, 2024

Mogyuchi commented Feb 12, 2024

Mogyuchi Feb 12, 2024

This comment was marked as spam.

Mogyuchi commented Feb 12, 2024

This comment was marked as spam.

jc-clark commented Mar 5, 2024

Mogyuchi commented Mar 7, 2024

fix: add necessary permissions to example workflow #31582

Are you sure you want to change the base?

fix: add necessary permissions to example workflow #31582

Conversation

corneliusroemer commented Feb 12, 2024 • edited

Why:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

github-actions bot commented Feb 12, 2024 • edited

Automatically generated comment ℹ️

Content directory changes

Mogyuchi Feb 12, 2024

Choose a reason for hiding this comment

corneliusroemer Feb 12, 2024

Choose a reason for hiding this comment

nguyenalex836 commented Feb 12, 2024

corneliusroemer commented Feb 12, 2024

Mogyuchi commented Feb 12, 2024

Mogyuchi Feb 12, 2024

Choose a reason for hiding this comment

This comment was marked as spam.

Mogyuchi commented Feb 12, 2024

This comment was marked as spam.

jc-clark commented Mar 5, 2024

Mogyuchi commented Mar 7, 2024

corneliusroemer commented Feb 12, 2024 •

edited

github-actions bot commented Feb 12, 2024 •

edited