![]() The GITHUB_TOKEN is limited to the current repository, which is great in most cases but prevents some workflows. This is possible when committing changes by setting the author email address, but not when adding an issue or pull request. Rather than showing github as the user, people would like to show a company branded account. This can be useful when changes are committed to a repository, or a comment is added to an issue or pull request. The other question I frequently see is “ Can we change the user shown for GITHUB_TOKEN?”. This is to prevent circular dependencies that can cause your builds to get stuck in a loop. GitHub decided that any actions performed by the GitHub Actions bot should not trigger events, which means that you can’t use a workflow to trigger another workflow whilst using the GITHUB_TOKEN secret. The number 1 question that I’ve seen around the GITHUB_TOKEN is “ Why doesn’t it trigger new workflow runs?”. These security considerations make the GITHUB_TOKEN the best choice when interacting with the GitHub API in your actions unless you have specific requirements that require a behaviour that the GITHUB_TOKEN can’t achieve. It cannot be used to make changes to any other repositories. Scope: The GITHUB_TOKEN is scoped to the repository running the workflow. You should make sure that you set the minimum permissions required using the permissions parameter. They can access it through the github.token context, including setting it as a default input in their action.yml. GitHub Actions that you use can access the GitHub token even if you don’t pass it in as an input. Secure: The GITHUB_TOKEN secret will not be shown in logs and can not be extracted from the runner via HTTP (trust me, I’ve tried)Īvailable by default: This is important. Staying with the security theme, there are a lot of security considerations around GITHUB_TOKEN in addition to being able to set granular permissions.Įxpiration: A new GITHUB_TOKEN is generated when each job begins, and the token expires when the job is finished The workflow file you use would look something like this: If it’s a major change, you want to automatically add a comment explaining why the PR won’t be immediately merged. Imagine that you work on a team where you use labels to mark pull requests as major, minor or patch version changes. This is huge, as it means that a rogue action can only perform the actions that you’re expecting a workflow to do. GITHUB_TOKEN allows you to specify which permissions the token is granted. I’m going to say that one more time for the people in the back. I'm going to lead with this as it’s key but not many people know about it. ![]() It works well enough for the majority of cases, so you probably haven’t thought too much about it.Įven though it’s just there, there’s a lot to GITHUB_TOKEN. Working with GITHUB_TOKENīefore we move on to personal access tokens and GitHub Apps, I want to spend a little time talking about the magical GITHUB_TOKEN secret that GitHub provide. It’s entirely up to you which route you choose. A PAT is much simpler to set up, but a GitHub App is a lot more powerful. The good news is that you’re not out of luck! You’ve got two options for working with the GitHub API - a personal access token (or PAT) and a GitHub App. This is awesome for 90% of the things you’d want to do with GitHub Actions, but what about the remaining 10%? The tasks where GITHUB_TOKEN doesn’t have the correct permissions, or when you want to trigger another GitHub Action somehow, but the GITHUB_TOKEN key won’t let you? GitHub automatically generate a token for you, and it’s only available whilst your workflow jobs are running. This token allows you to interact with the GitHub API and push or pull a repositories contents. If you’ve done any work with GitHub Actions, you’ve probably come across the GITHUB_TOKEN secret.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |