So I've been working on a couple of projects using Github Actions, and have come across PullApprove which is able to get the author_association from somewhere and use it. I'd like to setup some commands, which are restricted to author_association == collaborators, but am unsure how to go about this. Any advice would be appreciated.
Some code if you want it:
name: Command Management
on:
issue_comment:
types: [created, edited]
jobs:
# Automatically reverts commits on request
revert-commit:
runs-on: ubuntu-latest
if: contains(github.event.comment.body, '/revert')
steps:
- name: Checkout
uses: actions/checkout#v2.3.1
- name: Automatic Revert
uses: srt32/revert#v0.0.1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
For what it's worth, I can tell you that in PullApprove we use the PR author_assiciation from the REST API. Looks like there is actually a similar thing for issue comments, but not in the REST API or webhook events -- I think you'd have to make a call to the GraphQL API to get that info (get the node_id for the issue comment off of the event and use that to make a call to GraphQL as a custom step in your action?): https://docs.github.com/en/graphql/reference/objects#issuecomment
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.
I want to read version from a file and create tag as v11.0.5.1.aws using the workflow . Then I want to use that tag in the docker image.
For that, I have created a branch as devops.
First created a VERSION file as
1.1.3 20 Apr, 2022
Created a workflow as release-version.yml
name: Release Version
on:
push:
branches:
- devops
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Bump version and push tag
uses: melheffe/version_release_composer#master
env:
PREPEND: 'v'
APPEND: '.aws' # must include '.' or it will append without separation
DRAFT: 'false'
PRERELEASE: 'true'
TOKEN: ${{ secrets.AUTH_TOKEN }}
TRIGGER: ${{ github.event.pull_request.base.ref }} # can use the triggering branch or define a fixed one like this: 'master'
REPO_OWNER: rohit
VERSION_FILE_NAME: 'VERSION'
Then created another workflow as ci.yml which will get tag from release-version workflow
name: CI
# Only trigger, when the build workflow succeeded
on:
workflow_run:
workflows: ["Release Version"]
types:
- completed
jobs:
# This workflow contains a single job called "build"
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
DeployDev:
# Steps represent a sequence of tasks that will be executed as part of the job
name: Deploy to Dev
needs: [Build]
runs-on: ubuntu-latest
environment:
name: Dev
steps:
- uses: actions/checkout#v2
with:
token: ${{ secrets.AUTH_TOKEN }}
- name: Build, tag, and push image to Amazon ECR
id: build-image
#env:
# IMAGE_TAG: ${{ github.sha }}
run: |
# Build a docker container and push it to ECR so that it can
# be deployed to ECS.
echo "$GITHUB_REF_NAME"
docker build -t ${{secrets.ECR_REPO_URI}}/${{secrets.REPO_NAME}}:$GITHUB_REF_NAME .
docker push ${{secrets.ECR_REPO_URI}}/${{secrets.REPO_NAME}}:$GITHUB_REF_NAME
I'm able to trigger release version workflow after making changes on devops branch but ci workflow is not getting triggered after triggering the release-version.
Any suggestion will be helpful for me.
If the workflow_run trigger isn't working as expected, there are two other ways to achieve what you want (triggering a workflow from another workflow, sending an input parameter from the first one to use in the second one).
The workflow_dispatch event.
The repository_dispatch event.
The documentation is very good about how to use them, but I'll add here some references that can help as well:
Triggering Github Action using a POST request (Github REST API)
How to trigger a workflow_dispatch from Github API?
Triggering GitHub workflow using gh CLI
As you can see, you can trigger those events using directly the Github API in a step (with a CURL request) or using some actions from the Github Marketplace that perform the same operation.
The answer below also explains the difference between both events (as they are similar, and CURL payload differences may be confusing)
Correct request with client-payload to run workflow_dispatch in github action
I'll also add here an example that can be useful to understand how to use the repository_dispatch event to receive a callback from the other workflow to the first one:
workflow A
workflow B
Note that you will also need to use a PAT to trigger a workflow using a dispatch event.
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 making a Github Action for the launch of Marketplace.
https://github.com/dooboolab/relay-schema-bot
Can't I use the secret value of the repository when using the Github Action of another repository?
In other words, I want to use the secret value of the repository to be called, not the secret value of the calling side.
I want to do it in a way other than this.
because the secret value of the Jay-flow/relay-schema-bot repository is not used.
name: Relay Schema bot
on:
push:
branches:
- master
paths:
- 'schema.graphql'
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: dooboolab/relay-schema-bot#master
with:
token: ${{ secrets.PAT }}
repo-url: https://github.com/Jay-flow/artifacts-pro
# I don't want to enter it as below.
# because the secret value of the Jay-flow/relay-schema-bot repository is not used.
app-id: ${{ secrets.APP_ID }}
app-private-key: ${{ secrets.APP_PRIVATE_KEY }}
The APP_PRIVATE_KEY value is required to make a pull request from the Github application I created. The problem is that the user should not know this value.
Is there any way to make this possible?
Note
https://github.com/dooboolab/relay-schema-bot/blob/master/src/createPullRequest.ts#L18
This does not seem possible, from the documentation encrypted secret.
either the user of your action is able to provide the secret which will enable said action to create PR on the target repository
or your action might call a dedicated action on that target repo, and said dedicated action would be in charge to return the appropriate secret.
But then, nothing would prevent another user to call the same dedicated action on the target repository: the secret would be a secret no more.
Problem: We use github actions workflow for CI and we have many github repositories. I need to be able change everything repeatable for every repository at once.
Is it possible to use in github action workflow yml file some snippet that located mb in different repository.
You can include other public and local actions in your workflow, which lets you reuse common steps. Using versioned actions with {owner}/{repo}#{ref}:
steps:
- uses: actions/setup-node#74bc508 # Reference a specific commit
- uses: actions/setup-node#v1 # Reference the major version of a release
- uses: actions/setup-node#v1.2 # Reference a minor version of a release
- uses: actions/setup-node#master # Reference a branch
..or local actions with ./path/to/dir:
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout#v2
- name: Use local my-action
uses: ./.github/actions/my-action
https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsuses
One way of doing this is having a central CICD / GitHub actions repository with shared workflows which are triggered on repository_dispatch events.
on:
repository_dispatch:
types:
- your_event
jobs:
job1:
name: Do something
runs-on: ubuntu-latest
env:
SOURCE_BRANCH: ${{ github.event.client_payload.source_branch }}
SOURCE_REPO: ${{ github.event.client_payload.source_repo }}
# do all your stuff
Then in each github repo you write a small workflow file which outlines the triggers for the local repo, pushing to master / opening a PR etc. That action simply dispatches a repository_dispatch event to your central CICD repo with the repo and branchname it came from.
name: Trigger external CICD
on:
push:
branches:
- master
jobs:
trigger_cicd:
name: Trigger external CICD
runs-on: ubuntu-latest
steps:
- name: Send repository_dispatch event
uses: peter-evans/repository-dispatch#v1
with:
token: ${{ secrets.CICD_GITHUB_TOKEN }}
repository: yourorg/centralcicdrepo
event-type: ${{ env.EVENT_TYPE }}
client-payload: '{"source_branch": "${{ github.ref }}", "source_repo": "${{ github.repository }}" }'
One gotcha is that you need an access token to talk between repos, in the above example it's added as a secret called CICD_GITHUB_TOKEN. The easiest is to just use your own account but this will label all your central CICD runs as 'triggered by you'. You can also create a bot account or you can have each developer add their access tokens as secrets then map the right author to the right access token.
There is currently (Feb. 3, 2021) no supported method for reusing workflows or snippets from a centralized repository. There are hacks, as Michael Parker has cleverly demonstrated, but these come with significant downsides (eg. observability, opacity, etc.).
I've written this blog post that describes the problem you have in more detail, along with an open-source solution.
––
Similar topics:
DRYing GH Actions workflows
External workflow configuration
Bringing this issue to GH's attention:
Raise this issue with GH
GH Roadmap item