I have a GitHub page being deployed on my main repo (x.github.io). This website is being update through GitHub actions from others repo which pushes files to this main repo. The action pages-build-deployment is triggered each time there's a push to the main repo. However, some pushes take place close to one another, so the pages-build-deployment gets canceled and reruns in order to deploy the latest version of the website.
How can I stop this behavior so that it doesn't get canceled and instead finishes the current deployment?
You should try defining concurrency at your workflow.
ex.:
concurrency:
group: ${{ github.workflow }}
cancel-in-progress: false
More info: here and here
Related
We have a GitHub Actions workflow triggered by the creation of a release, i.e.,
on:
release:
types: [created]
How can we add the built files to the triggereing release as an asset from within the workflow?
I have seen this answer recommending softprops/action-gh-release, but that seems to apply to workflows triggered by pushes (with tags) and not "on release".
You can use the same action with the on: release trigger.
The GITHUB_REF environment variable or GitHub.ref context variable should contain the tag of the release.
See:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release
Another way to add files to the workflow is to use the GitHub CLI:
gh release upload $GITHUB_REF path/to/file path/to/file etc
That way you don't need to pull in actions from the marketplace.
${{ github.event.release.tag_name }}
Is another way to access the tag name.
In our github repository, we have set up a protected environment named Sandbox, for which the main branch is the only allowed deployment branch. Now we want to deploy automatically to that environment if a pullrequest is merged into main (and the if the pullrequest in addition bears the label "Sandbox").
Our workflow is roughly as follows:
name: Pull Request Merged
concurrency:
group: ${{ github.ref }}
on:
pull_request:
types: [closed]
jobs:
deploy_to_sandbox:
if: |
github.event.pull_request.merged == true &&
contains(github.event.pull_request.labels.*.name, 'Sandbox')
name: Deploy to Sandbox
uses: ./.github/workflows/deploy.yml
with:
environment: Sandbox
secrets: inherit
The workflow is triggered as expected upon merging a PR, but somehow it tries to deploy from the feature branch instead of deploying from main. Since the environment is protected, the deployment fails accordingly. How can we achieve that the deployment uses the target branch (i. e. , main) that was merged into, instead of the source branch?
There’s no way to specify that a workflow should be triggered when a pull request is merged. the reason why it's the feature branch that gets deployed is because it's the one that triggers the workflow. However, because a merged pull request always results in a push, you can use the push event to accomplish your goal.
For example, let’s say that you want to run a workflow whenever a pull request is merged to your main branch. You can do something like this:
on:
push:
branches:
- main
also if you want to prevent push directly to main it's part of github pro plan.
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:
...
We have two workflow that trigger on push set up like this:
on:
push:
branches:
- master
Inside of one workflow, it contains an action that push a bump version commit into master.
Inside of the other, it validate if the commit message is a bump and deploy automatically.
Currently, when we push a commit to master, we can see the github action created a commit in master like this:
Automated Version Bump ci: version bump to v1.2.3
Where Automated Version Bump is the name of the GitHub action and ci: version bump to v1.2.3 is the commit message generated by the GitHub action
I was expecting the workflow to trigger again because of the automated commit.
Does that means Automated Commit does not trigger workflow hook?
Thank you!
It seems this behaviour is a feature.
From the workflow events page:
An action in a workflow run can't trigger a new workflow run. For
example, if an action pushes code using the repository's GITHUB_TOKEN,
a new workflow will not run even when the repository contains a
workflow configured to run when push events occur.
So basically, events that originate from a workflow cannot trigger other workflows.
An alternative would be to use a scheduled workflow that checks every couple hours or so and does the validation.
on:
schedule:
- cron: '0 0/2 * * *'
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.