https://pulumi.com
Join Slack
<@UKHFQ233Q> <@UMP2PT80L> <@U04LG89SXS8> hopefully one step closer to having PRs from forks of `infr...
# pulumiverse
l
@big-architect-71258 @elegant-window-55250 @cuddly-flower-91328 hopefully one step closer to having PRs from forks of 
infra
working: https://github.com/pulumiverse/infra/pull/230
b
@limited-rainbow-51650 left a comment in the PR šŸ™‚
@limited-rainbow-51650 merged
l
Still the same: ā€¢ PR https://github.com/pulumiverse/infra/pull/231 ā€¢ Run triggered by 
pull_request
, not `pull_request_target`: https://github.com/pulumiverse/infra/actions/runs/11294305085
b
@limited-rainbow-51650 Could it be the order in which 
pull_request
and 
pull_request_target
are defined and thus should 
pull_request_target
before 
pull_request
?
@limited-rainbow-51650 Merged it ... Not sure if 
pull_request_target
will now be called/triggered if you rebase your PR or if this only might happen on a brand new change.
Oh and by the time I'm writing this: if this now works we must add the defined included paths as negated paths to 
paths-ignore
to ensure that no one could start a workflow using 
pull_request_target
that might change/add a workflow by adding "usesless" commits to the paths for the configuration files.
l
b
YEEEHAAAWWWW meow party
giphy.webp
giphy.webp
Wondering why GitHub triggered the workflow twice?
@limited-rainbow-51650 What I planned to do "ensure that pull-request-trigger is only triggered when there are changes to the configuration" seems not to be possible. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore I think we need a combination of 
paths-ignore
and 
paths
and the two triggers, where 
pull-request
must be first with 
path-ignore
settings according to 
paths
of 
pull-request-target
.
@limited-rainbow-51650 Updated the configuration like so
Copy code
name: Pull Request
on:
  pull_request:
    paths-ignore:
      - '01-teams/**'
      - '02-repositories/**'
      - '03-members/**'
      - '.github/workflows/provider-*.yaml'
  pull_request_target:
    paths:
      - '01-teams/**'
      - '02-repositories/**'
      - '03-members/**'
So in THEORY šŸ˜„ 
pull_request_target
will only get triggered if and only if there are changes to the configuration files.
l
@big-architect-71258 what if you have changes to the implementation which requires changes to the config files? Take Engin's changes for archiving repositories: that requires changes to the TypeScript files and a change to the config files to test it at least on one repo. That isn't covered anymore.
b
@limited-rainbow-51650 The idea is that 
pull_request_target
will only work for changes to the configuration files, because other changes to the code or the GitHub workflows have the inherent problem that secrets could be stolen. And everybody, even a malicious actor, can open a pull request via fork. Changes to code or the GitHub workflow should only be processed via pull requests of people who have direct access to the repo, because that we can control.
4 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by