Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use built-in token where possible #1087

Open
danielrbradley opened this issue Oct 1, 2024 · 0 comments
Open

Use built-in token where possible #1087

danielrbradley opened this issue Oct 1, 2024 · 0 comments
Labels
kind/enhancement Improvements or new features

Comments

@danielrbradley
Copy link
Member

danielrbradley commented Oct 1, 2024 •
edited
Loading

When working within a single repo we should use built-in tokens and not the full bot access token.

Applies to:

Related to #1053
@danielrbradley danielrbradley added the kind/enhancement Improvements or new features label Oct 1, 2024
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Oct 1, 2024
@danielrbradley danielrbradley changed the title Use built-in token when checking for upstream updates Use built-in token where possible Oct 1, 2024
@danielrbradley danielrbradley removed the needs-triage Needs attention from the triage team label Oct 1, 2024
This was referenced Oct 8, 2024
Closed
Merged
github-merge-queue bot pushed a commit that referenced this issue Oct 15, 2024
@ringods
Use the standard Github generated token with elevated permissions (#1099
a93c701 
)

Relates to: #1053, #1087

Moving from a central `PULUMI_BOT_TOKEN` to the Github Actions
permissions block makes the workflows reusable for third party
providers. The generated `GITHUB_TOKEN` secret in each workflow instance
will receive elevated permissions based on the permissions configuration
block. To limit the blast radius of a possible error, this PR focuses on
the `main|master` and `(pre)release` workflows for now. Similar changes
for other workflows will come in subsequent pull requests.

Besides making the workflows more reusable for third-party providers, it
also improves on the situation for rate limits tied to the central
`PULUMI_BOT_TOKEN`. The generated `GITHUB_TOKEN` has [much higher API
rate
limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#primary-rate-limit-for-github_token-in-github-actions)
on our Github Enterprise backed subscription for `pulumi` organization:

> The rate limit for `GITHUB_TOKEN` is 1,000 requests per hour per
repository. For requests to resources that belong to a GitHub Enterprise
Cloud account, the limit is 15,000 requests per hour per repository.

Already moving the `main|master` and `(pre)release` workflows to use the
`GITHUB_TOKEN` reduces the usage of the `PULUMI_BOT_TOKEN`, so lowering
the chance of bumping into a rate limit.

Github Docs: [Controlling permissions for
`GITHUB_TOKEN`](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token)

**NOTE:** The required permissions for the `publish` workflow are set on
the calling side of the nested job instead of within the nested job. I
tested setting it within publish.yml but it seems it is not possible
anymore to elevate permissions in a nested job:
https://github.com/pulumiverse/pulumi-acme/actions/runs/11181469935

The changes of this PR are validated in the following third-party
packages:

| Package | Commit with changes from this PR | Green `main` run | Green
`release` |
|--------|--------|--------|--------|
| [pulumiverse/pulumi-acme](https://github.com/pulumiverse/pulumi-acme)
|
[33e7fa5](pulumiverse/pulumi-acme@33e7fa5)
|
[11182399934](https://github.com/pulumiverse/pulumi-acme/actions/runs/11182399934)
|
[11182413642](https://github.com/pulumiverse/pulumi-acme/actions/runs/11182413642)
|
|
[pulumiverse/pulumi-matchbox](https://github.com/pulumiverse/pulumi-matchbox)
|
[f370a12](pulumiverse/pulumi-matchbox@f370a12)
|
[11232745061](https://github.com/pulumiverse/pulumi-matchbox/actions/runs/11232926252)
|
[11182413642](https://github.com/pulumiverse/pulumi-matchbox/actions/runs/11232926252)
|
This was referenced Nov 4, 2024
Merged
Merged
github-merge-queue bot pushed a commit that referenced this issue Nov 26, 2024
@ringods
Make upgrade workflows more accessible to third parties (#1128)
3211fa3 
The`PULUMI_BOT_TOKEN` requirement for third parties is not very
intuitive and the upgrade workflows fail without this available.

1. Add the option to use `PULUMI_PROVIDER_AUTOMATION_TOKEN` instead of
the `PULUMI_BOT_TOKEN` as a more descriptive alternative.
2. Add fallback if no PAT is available to use the built-in GitHub
Actions token. A `permissions` block is therefore also added to allow it
to push commits, create Github issues and pull requests in the
repository.

Using the built-in token has the downside that the created PR will not
be automatically built because it was created by an App ([see the
docs](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow)
for details).

Internally, we should also switch to using
`PULUMI_PROVIDER_AUTOMATION_TOKEN` instead of `PULUMI_BOT_TOKEN` as it's
a better name that describes its purpose better within the ever-more
crowded list of org-level secrets.

Contributes to: #1087
@ringods ringods mentioned this issue Dec 17, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/enhancement Improvements or new features
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@danielrbradley @pulumi-bot