I have a simple Node JS application built in the build directory using yarn and trying to deploy on GitHub Pages using GitHub Actions using crazy-max/ghaction-github-pages#v2 actinon in the simplest form:
- name: Deploy
uses: crazy-max/ghaction-github-pages#v2
with:
target_branch: master
build_dir: build
env:
$GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
(Note I deploy to master because the repository name is equal to the <<username>>.github.io)
To my surprise, it fails on the following error:
Error: You have to provide a GITHUB_TOKEN or GH_PAT
The whole message is not helpful as long as I know the GITHUB_TOKEN is automatically generated with each build.
The repository has the following settings under Action:
Actions permissions: Allow all actions
Fork pull request workflows from outside collaborators: Require approval for first-time contributors
Workflow permissions: Read and write permissions
The whole token and permissions management in GitHub is overkill for simple projects and the documentation lacks sample settings and the reader only goes down the rabbit hole.
How to get this run?
Based on the documentation I'm reading, it looks like you need to remove the leading $ from your environment variable name you are setting
Like this:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Documenation:
https://github.com/crazy-max/ghaction-github-pages
Related
I have a workflow, that does some modifications on the repository, and pushes it, expecting the push workflow to start. Now I know that the intended way in the documentation suggests me creating a PAT, but that seems like a hacky solution to me, since the whole build procedure is tied to my account being active and having necessary permissions.
It also expects my account to have push access to my main branches, which I don't want to have. I want to operate through PRs.
Do I have any other options? Do I need to create a my-github-bot account in my org and create a PAT for that? All these options seem too hacky compared to just having a switch to enable workflow triggering with the default ${{ secrets.GITHUB_TOKEN }}
The workflow that pushes can also use the workflow_dispatch trigger on the second workflow to start the other workflow. Either by doing a REST call or by including a call gh:
gh workflow run {{workflow.yaml}} --ref {{sha}} --repo {{owner/repo}}
Or use one of the available actions to invoke the workflow after your push step.
For example:
- name: Invoke workflow with inputs
uses: benc-uk/workflow-dispatch#v1
with:
workflow: Another Workflow
You can also use a GitHub app, there's a special action for that. You grant the app the permissions to invoke the workflow and then let the workflow retrieve a token to invoke the other workflow if needed, heck, you could even use that token to do the push.
- name: Get Token
id: get_workflow_token
uses: peter-murray/workflow-application-token-action#v1
with:
application_id: ${{ secrets.APPLICATION_ID }}
application_private_key: ${{ secrets.APPLICATION_PRIVATE_KEY }}
- name: Use Application Token to create a release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ steps.get_workflow_token.outputs.token }}
with:
....
A bit of setup is required to register the app and give it the right permissions.
GitLab has an extremely useful feature called Review Apps which allows you to start up an instance of the web app from every PR which has its own subdomain and is linked on the PR page. I have done some searching and I don't see anything quite like it for GitHub.
Are there any ways to achieve a similar thing on github? 3rd party services are fine if they can integrate in with github. The app has a docker compose config so it would be just starting up an instance on a VM and shutting it down later.
The closest would be Delivering deployments/Deployment API, as described in the article "Deploy your pull requests with GitHub Actions and GitHub Deployments" from Sander Knape.
You can see its workflow here.
But the point is: there is not a directly integrated "review" deployment process like GitLab: you need to write your own GitHub workflow in order to deploy on a GitHub-managed Azure-based server, starting with:
deploy:
runs-on: ubuntu-latest
needs: deploy-check
if: needs.deploy-check.outputs.triggered == 'true'
steps:
- name: get pull request ref
id: get_pull_request_ref
uses: octokit/request-action#v2.x
with:
route: GET /repos/:repository/pulls/:issue_id
repository: ${{ github.repository }}
issue_id: ${{ github.event.issue.number }}
env:
GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
I'm on the CI part of the course
I'll start by saying all works well, and I could follow the process with ease. However, there something that works, and I cannot figure out how. Lets take this part of the main.yml file:
- name: Log in to GitHub Packages
run: echo ${GITHUB_TOKEN} | docker login -u ${GITHUB_ACTOR} --password-stdin docker.pkg.github.com
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
I have these params like GITHUB_ACTOR and GITHUB_TOKEN, that I didn't define as any part of my code, or write into a panel inside github. Are they automaticly filled in by github? If I change my token, will this code still work?
Thanks in advance
This is documented in "Automatic token authentication"
At the start of each workflow run, GitHub automatically creates a unique GITHUB_TOKEN secret to use in your workflow.
You can use the GITHUB_TOKEN to authenticate in a workflow run.
When you enable GitHub Actions, GitHub installs a GitHub App on your repository.
The GITHUB_TOKEN secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository. The token's permissions are limited to the repository that contains your workflow
You have Default environment variables, including:
GITHUB_ACTOR: The name of the person or app that initiated the workflow.
For example, octocat.
I would like to use a GitHub action/do some config that automatically requests a review from a team in a GitHub organization (for example core). I know that you can create pull request templates that automatically request a review from a certain reviewer but how do I do this without creating a template? In summary, I would like to have a team in GitHub core automatically requested a review for each PR opened. How do I do this?
In general, this is a good use case for the code owners feature: you could have a file .github/CODEOWNERS that looks like
* #yourorg/core
This requires a review from that team on any pull request opened.
However, this requires the team to have write permissions on the repository, and (as per comments) the intention is to not give this team write permissions.
With the team having only "triage" permissions, this could be achieved with the following workflow:
name: Request review on PRs
on:
pull_request:
types:
- opened
jobs:
request:
name: Request reviews on opened PRs
runs-on: ubuntu-20.04
steps:
- name: Create PR review request
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh pr edit ${{ github.event.pull_request.html_url }} \
--add-reviewer yourorg/core
This runs on each opened pull request and creates a review request from the yourorg/core team using the pr edit command of the GitHub CLI, which is pre-installed on the virtual environments.
Currently I have the following code:
name: Build-All
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build-linux-64:
name: ${{ matrix.config.name }} Build
runs-on: ${{ matrix.config.os }}
strategy:
fail-fast: true
matrix:
config:
- os: ubuntu-latest
name: Ubuntu 64
other_linker_flags: '-m64'
arch: x86_64
output: myLib.so
steps:
- name: Make fake file
run: |
echo "hello" > ${{ github.workspace }}/test.txt
- name: Uploading Release
uses: ollydev/upload-release-action#master
with:
repo_token: XXXXXXXXX
file: '${{ github.workspace }}/test.txt'
asset_name: "test"
tag: autobuild
owner: '${{ github.repo.owner }}'
repo: 'B'
overwrite: true
and two repos: A and B.
Repo A has the above yml jobs and it is a private repo. It has all the code, compiles it, and wants to push the release to repo B which is public.
To do this, I created a new github account My-CI and I added it to both the private repo and the public repo. On that new account, I then created a Personal access token with scope: public_repo
and that's it. The code works.. but is there a way to NOT have to create a separate account just to give it access as a CI to both repos? IE: Is there a way that I can create a token on my real account that is read-only for one repo and read-write for another? OR maybe create a github app token or something that can only upload releases for the one repo (B)?
As you've implied, you can't limit the scope of a personal access token to different scopes for different repos. Theres a few ways of doing this.
Intermediate, public storage
The first is to upload the artifacts to an intermediate place, accessible from anywhere, e.g. Dropbox, Docker Hub, etc. Then you can manually trigger a github action in your public repo to pull this artifact back down and create a release from it. To manually trigger this action you could use the repository_dispatch event either using cURL / postman locally (with an access token auth bearer) or using something like https://www.actionspanel.app/ which is a github app which allows you to manually trigger github actions using repository_dispatch, with parameters so your download link would be a parameter.
Personal access token
The simplest option is still a personal access token though. Your workflow above has repo_token: XXXXXXXXX which makes me wonder if you know about github secrets? Ideally this token would be stored in a secret then accessed using ${{ secrets.BRANDONS_TOKEN }}. I would ask why you are worried about a personal access token. If you use github secrets and are careful about the 3rd party code you pass the token to (you may not want to simply pass your token to #master, for example), it should be fine.
GitHub Apps & Webhooks
GitHub apps or webhooks would be another way, you can authenticate those on a per-person basis and per-repo basis but you'd need an application running online to receive and parse the messages and its quite a big piece of work.
(Probably not) GitHub Deploy Keys
Another thing to be aware of is Github Deploy Keys, you can use these to obtain read/write access to a single repository without an account attached. You would then store this deploy key in a secret in the settings of the other repo. However, I'm not sure you can trigger releases with deploy keys - they are not bound to an account so I'm unsure who's username would be visible on the release history.