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.

Pulumi Community

<@UKHFQ233Q> <@UMP2PT80L> <@U04LG89SXS8> hopefully one step closer to having PRs from forks of `infra` working:
<https://github.com/pulumiverse/infra/pull/230>

<@UK4HNFLCB> left a comment in the PR :slightly_smiling_face:

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>

<@UK4HNFLCB> Could it be the order in which `pull_request` and `pull_request_target` are defined and thus should `pull_request_target` *before* `pull_request`?

<https://github.com/pulumiverse/infra/pull/232>

<@UK4HNFLCB> 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.

`pull_request_target`!!!
<https://github.com/pulumiverse/infra/actions/runs/11294706502>

giphy.webp

image.png

Wondering why GitHub triggered the workflow twice?

<@UK4HNFLCB> 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`.

<@UK4HNFLCB> Updated the configuration like so

```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 :smile: `pull_request_target` will only get triggered if and only if there are changes to the configuration files.

<@UKHFQ233Q> 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.

<@UK4HNFLCB> 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.