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.

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

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

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
github-merge-queue bot pushed a commit that referenced this issue Oct 15, 2024
)

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)
|
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

2 participants