I am playing with github actions and trying to do something whenever other check is completed. I see 0 runs for this action.
This action is available in master branch and I am opening PR to the master.
I've tried to capture events via webhooks and I receive events there just fine. Why is my action not working?
Code below:
name: on check run
on:
check_run:
types: [ completed, rerequested, completed, requested_action]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: ENV
run: env
- name: check out event
run: cat "$GITHUB_EVENT_PATH"
update
I also tried to have other checks in the repository (travis ci), the action is still not executed.
update 2
It turned out I was looking for different event that I needed. I confused status even with "check run" event. Travis ci in it's default setup produced "status" event, "check" api needs to be enabled separately
I think the issue might be that the GitHub Checks API support on Travis was only added to travis-ci.com. So if your checks are running on travis-ci.org you need to migrate.
See this blog post for the announcement.
https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com
It is available to private and open source projects using travis-ci.com
This is the announcement about migration of
https://blog.travis-ci.com/2018-09-27-deprecating-github-commit-status-api-for-github-apps-managed-repositories
As part of our gradual migration to GitHub Apps for our GitHub integration, we’re formally deprecating GitHub Commit Status API updates for repositories on travis-ci.com managed by GitHub Apps. Instead, these repositories will have status updates reported to the GitHub Check Runs API.
Related
In GitHub job workflows a github action is typically referenced by version for example actions/checkout#v3
jobs:
build:
steps:
- name: Checkout repository
uses: actions/checkout#v3
when I visit the Action's releases page I see that the current version is 3.2.0.
Questions:
When referencing an action using the actions/checkout#v3 does it use the most recent minor version when the action when the workflow is executed.
If I run the above job will it use version 3.0.0 of the action or version 3.2.0?
It uses the explicitly specified version or tag. For a public action the format is {owner}/{repo}#{ref} in which {ref} can be a Git tag, branch or SHA. See the relevant documentation for more details.
Whether a GitHub Action offers major tags (e.g. v3) is at the discretion of the action maintainers. If it is offered, usually the major tag is force pushed to point to the same commit as the new minor version tag when a new minor version is released.
For example, actions/checkout has a helper workflow (see update-main-version) which can be manually triggered to do this. Many other actions use actions/publish-action despite currently being in alpha development and GitHub does "[...] not recommend this action for public or production usage while it is still in development." The purpose is to update the major version tag or create a new one if it does not exist yet.
I'm working in a company that uses Github Actions and Argocd.(using argocd helm chart).
Needless to say that the Github repo is private and argocd is in an internal network that used by the company only.
The flow of what we want to do is that when we deploy the app and the deployment succeeded - Trigger another workflow that will run tests on the deployed environment.
Basically, the deployment will be the trigger for another workflow.
I have been trying to configure webhook from argocd to github but with no success.
What is the best approach to this situation, will be happy to provide more context if needed.
Edit:
The test workflow i'm trying to use workflow_dispatch.
name: workflow_02
on:
push:
branches: [ argo-github-trigger ]
workflow_dispatch:
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Worked"
I'm expecting to see a "Run workflow" button on github but it doesn't appear. On another repo, that I have Admin priviliges and can work on the main branch, I tried the same workflow and it worked.
The best approach would be to use a post sync hook.
Why is it necessary to run the tests in a GitHub actions workflow? Since the application is already deployed to the cluster, wouldn't it make more sense to run the tests directly on the cluster, instead of going through the trouble of communicating with Github?
I'm trying to use a Google Cloud Build Trigger to trigger a Cloud Build and then deploy to Cloud Run upon a Pull Request to Github repo Branch. My console looks as follows:
My questions:
Is it possible to only trigger once the PR is approved or merged? Right now it triggers upon creation of the PR. I'd prefer to only build and deploy once my inevitable mistakes in the PR are corrected.
It seems to build the feature branch I'm attempting to merge, not the main. Am I misunderstanding what Base branch means? Is that not the branch that it should build once I merge to it?
Inline YAML from the trigger:
steps:
- name: gcr.io/cloud-builders/docker
args:
- build
- '--no-cache'
- '-t'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
- .
- '-f'
- Dockerfile
id: Build
- name: gcr.io/cloud-builders/docker
args:
- push
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
id: Push
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim'
args:
- run
- services
- update
- $_SERVICE_NAME
- '--platform=managed'
- '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
- >-
--labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS
- '--region=$_DEPLOY_REGION'
- '--quiet'
id: Deploy
entrypoint: gcloud
images:
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
options:
substitutionOption: ALLOW_LOOSE
substitutions:
_DEPLOY_REGION: europe-west1
_LABELS: gcb-trigger-id=c764048b-0347-4f67-8a6f-93a91f4b05af
_TRIGGER_ID: c764048b-0347-4f67-8a6f-93a91f4b05af
_GCR_HOSTNAME: eu.gcr.io
_PLATFORM: managed
_SERVICE_NAME: myservice
tags:
- gcp-cloud-build-deploy-cloud-run
- gcp-cloud-build-deploy-cloud-run-managed
- myservice
Make a trigger that triggers on the "Push to a branch" event
Set the branch to ^main$
That's pretty much it. Then whenever you merge a pull request it will trigger the build.
To answer your questions:
Is it possible to only trigger once the PR is approved or merged? Right now it triggers upon creation of the PR. I'd prefer to only build and deploy once my inevitable mistakes in the PR are corrected.
It is possible by using manual approvals. The user must have a Cloud Build Approver role in order to update a trigger to require or not require approval, meaning the user can approve or reject builds. You can check this documentation on gate builds on approval.
Another option is defining an organizational policy to control which external services can invoke build triggers. You can specify any number of allowed or denied values for your organization or project. You can check this documentation on gate builds on organizational policy.
Comment control must also be set to required so that builds will only be executed after an owner or collaborator comments /gcbrun so that builds won't be automatically executed by triggers. You can check the full steps here on creating a GitHub trigger.
It seems to build the feature branch I'm attempting to merge, not the main. Am I misunderstanding what Base branch means? Is that not the branch that it should build once I merge to it?
When you create a trigger, you will be asked to select a base branch (either main or any other branch that will be read after providing your GitHub repo). In my case, it listed two.
When you make changes in your repo and open a pull request, it will merge the changes from your head branch to your base branch (in this case your main).
You can check the full documentation on working with branches.
I have a Github page that automatically gets updated when I push to master. I would like to run a Github action that would trigger when the website gets published.
This would allow me to get the updated RSS feed and update my social media accounts anytime I push a change to the website.
Is it possible to run a Github action when the website changes and after it is published?
Or is it possible to turn off the GitHub page publishing and create a workflow that I have control of and publish myself?
GitHub Pages uses deployments to publish. The following workflow will trigger when a deployment was successful allowing you to update what you need to afterwards.
on: deployment_status
jobs:
publish:
if: github.event.deployment_status.state == 'success'
runs-on: ubuntu-latest
steps:
...
I just got a GitHub account and writing small scripts in Python which I am learning.
While adding my code to GitHub I noticed there is an option to run tests/validation on my code but mine is empty.
I googled around and found that lint and black and are good checks.
I found this Action that I want to add - https://github.com/marketplace/actions/python-quality-and-format-checker
There is a "script" and a "config" that I think I need to add/update somewhere. Also when I click "Use latest version" it tells me to add the code into some .yml.
Can anyone assist me in installing this Action or point me in the right direction? Also, how can I use this Action on all my repositories/code?
=======================================
EDIT:
This link has the instructions - https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow
place yaml or yml in this directory -> .github/workflows
For this Action: https://github.com/marketplace/actions/python-quality-and-format-checker
the code inside the file will look like this:
on: [push, pull_request]
name: Python Linting
jobs:
PythonLinting:
name: Python linting
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Konstruktoid Python linting
uses: konstruktoid/action-pylint#master
thanks to: bertrand martel
pylint is part of the new GitHub Super Linter (github/super-linter):
Introducing GitHub Super Linter: one linter to rule them all
The Super Linter is a source code repository that is packaged into a Docker container and called by GitHub Actions. This allows for any repository on GitHub.com to call the Super Linter and start utilizing its benefits.
When you’ve set your repository to start running this action, any time you open a pull request, it will start linting the code case and return via the Status API.
It will let you know if any of your code changes passed successfully, or if any errors were detected, where they are, and what they are.
This then allows the developer to go back to their branch, fix any issues, and create a new push to the open pull request.
At that point, the Super Linter will run again and validate the updated code and repeat the process.
And you can set it up to only int new files if you want.
Update August 2020:
github/super-linter issue 226 has been closed with PR 593:
This Pr will add:
Black python linting
Updated tests