I want to cancel the previous run when a new run is executed.
So, referring to the https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency document, I added the concurrency keyword.
Below is my sample code.
name: test
on:
push:
branches:
- feature/**
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
jobs:
~~~
However, when executing the action, an error saying "The key 'concurrency' is not allowed" is thrown and it does not work. The examples on google are no different from my sample code. What is the cause?
(If the concurrency keyword is removed, the action works normally.)
Tried the code you provided and it worked for me with no issue. Not sure what the problem is on your side. Are you running this on a GitHub-provided runner or are you self-hosting one? Can't gauge that since you job description is missing. Also do you have a link to the repository maybe?
Something to try would be to add the concurrency key on the job level instead of the global level. Maybe that changes things for you
Related
I have my domain and my hosting through one.com and I'm tired of moving individual files through filezilla and wanted to automate that process using github actions.
I guess I'll start out by saying I'm completely new to this and this is my first time trying to setup an action. Basically what I want is to just push the code to my github repo and then it gets build and sent to my host. Kinda like how it is with Netlify.
I stumbled upon this https://github.com/SamKirkland/web-deploy which should do the trick. I've seen tutorials using this method on youtube, but I guess they have a different provider than I do making it easier.
This is what information I have to go off of and I hope it will be enough to set it up:
Host: ssh.one-example.com
Username: one-example.com
Password: the one you chose for SSH in your Control Panel
Port: 22
and this is what I put in the yml file:
on:
push:
branches:
- main
name: Publish Website
jobs:
web-deploy:
name: 🚀 Deploy Website Every Commit
runs-on: ubuntu-latest
steps:
- name: 🚚 Get Latest Code
uses: actions/checkout#v3
- name: 📂 Sync Files
uses: SamKirkland/web-deploy#v1
with:
target-server: ${{ secrets.ftp_host }}
remote-user: ${{ secrets.ftp_username }}
private-ssh-key: ${{ secrets.ftp_password }}
destination-path: ~/destinationFolder/
I've tried having the target server both be ssh.one-example.com (obviously using my own here) and I've tried one-example.com#ssh.one-example.com
But I'm ending up with the following error when the action is running:
Error: Error: The process '/usr/bin/rsync' failed with exit code 255
So safe to say I'm a little lost and would like some guidance on how to make it work. Is it what I'm typing that's the issue, is it the host? And if so how do I fix it?
Any help is much appreciated.
Try an SSH action first, to see if you actually can open an SSH session. This is just for testing the connection: try and execute on the remote server a trivial command (ls, or pwd)
Then, regarding your current original action, check the error messages before your "The process '/usr/bin/rsync' failed with exit code 255".
See as an example of previous error messages SamKirkland/web-deploy issue 5 (not yet resolved).
I'm trying to set a github branch protection rule based on the success or failure of a github actions workflow.
You can see the workflow here:
https://github.com/apostrophecms/apostrophe/blob/main/.github/workflows/main.yml
The workflow passes, and I even have a working badge for it, but I am unable to set a branch protection rule requiring that it pass as a status check.
I can set a branch protection rule based on any one of the individual builds in the matrix, but I don't want to set all of them individually and keep track of that as my matrix rule changes.
As you can see from the screenshots, I am unable to pick "build", the name of the job (although I can pick any of the sub-builds), and I am also unable to pick "tests", the name of the workflow as a whole (it does not change if I use an uppercase t).
What am I missing? Thanks for your help!
Screenshot one: I can pick a sub-build but not the entire build job.
Screenshot two: I can't pick the name of the overall "Tests" workflow at all.
There's a trick to add one step to the workflow to collect all jobs from the matrix to one check:
tests:
runs-on: ubuntu-latest
needs: build
if: always()
steps:
- name: All tests ok
if: ${{ !(contains(needs.*.result, 'failure')) }}
run: exit 0
- name: Some tests failed
if: ${{ contains(needs.*.result, 'failure') }}
run: exit 1
if: always() is obligatory to collect failed tasks, otherwise PR will never get a proper status check. Also, this is an additional step for you to pay (if you use paid plans).
In this case, you have a single job with a matrix. That means you'll end with 9 possibilities (3 node options × 3 MongoDB options). Each of those is considered a separate status check and can be enabled or disabled as mandatory individually. This is so that you can add new options without making them mandatory up front.
If you want every one of those jobs to pass, then you need to choose every one of the 9 jobs and mark them as required.
I have the below error in github build with ghost inspector tests
"Error: timeout of 600000ms exceeded"
I tried maxTimeout in git build .yml file. But it's not working.
https://ghostinspector.com/docs/integration/github-actions/
If anyone knows this solution share it with me.
Instead of changing the concurrency in the ghostinpector, you can use the ghostinprctor-cli for run the git actions.
Ex:
https://ghostinspector.com/docs/api/cli/
- uses: docker://ghostinspector/cli
with:
args: suite execute ${{ secrets.GI_SUITE }} \
--apiKey ${{ secrets.GI_API_KEY }} \
--errorOnFail
secrets.GI_SUITE and secrets.GI_API_KEY are the ghostinspector API and SUITE keys. you can get those from the ghostinspector settings
secrets and the github secrets https://docs.github.com/en/actions/security-guides/encrypted-secrets
The above issue has based on concurrency limitations.
Previously I used 25 tests that not working.
Now I changed that 50 tests. Now, maxTimeout=600000ms is working correctly for me.
I want to run a GitHub Actions workflow for every successful commit (e.g. after all check suites have ran successfully).
It seems like the check_suite events will be fired for each individual check suite, and contain no information about the other suites. I want to wait for all registered check suites.
The status event seems to be exactly what I want:
Statuses can include a context to indicate what service is providing that status. For example, you may have your continuous integration service push statuses with a context of ci, and a security audit tool push statuses with a context of security. You can then use the combined status endpoint to retrieve the whole status for a commit.
But the status lives completely unrelated to the check_suites events, and most CI services now uses the check_suites (including GitHub Actions itself), and not status.
How can I, with a GitHub Actions workflow, check that all check_suites finished and the commit has successfully passed all checks and tests?
You can use the GitHub API to list the check suites belonging to a ref: https://octokit.github.io/rest.js/#octokit-routes-checks-list-suites-for-ref.
So, within your action (triggered by check_suite), you can list all the suites for the current ref, check they're all successful and then run your code.
If you're building a javascript action it could look like this:
import * as github from "#actions/github";
const response = await client.checks.listSuitesForRef({
owner: github.context.repo.owner,
repo: github.context.repo.repo,
ref: sha
});
const passes = response.data.check_suites.every(...)
if (passes) { ... }
The major drawback of this approach is that this very action is itself a check suite belonging to the current commit, so it will appear in response.data.check_suites (and will never be successful at this point ... because it's still running!). I don't have a solution for this part yet...
It looks like you are now able to trigger actions based on commit status (reference).
on:
status
jobs:
if_error_or_failure:
runs-on: ubuntu-latest
if: >-
github.event.state == 'error' ||
github.event.state == 'failure'
steps:
- env:
DESCRIPTION: ${{ github.event.description }}
run: |
echo The status is error or failed: $DESCRIPTION
I am using Azure pipelines with a Github-based project. I have set up a build pipeline that is triggered only by tagged commits, to keep it separate from automatic daily builds that happen at every commit.
I would like to exclude tagged commits from triggering the daily build pipeline. What is the correct way to do so in a yaml script?
Here is what I did, without success.
According to Azure documentation at this page, to my understanding excluding tags should be possible with something like:
trigger:
tags:
exclude:
- projectname_v*
However, this does not work, and just prevents the build pipeline to run at any commit, be it tagged or not.
I have also tried:
trigger:
tags:
include:
- *
exclude:
- projectname_v*
but this is apparently not supported, as it produces error:
/azure-pipelines.yml: (Line: 12, Col: 7, Idx: 220) - (Line: 12, Col: 8, Idx: 221): While scanning an anchor or alias, did not find expected alphabetic or numeric character.
I have also tried the alternative syntax proposed on the doc page:
trigger:
branches:
exclude:
refs/tags/{projectname_v*}
as well as variants with/without braces and wildcards, but all fail with "unexpected value" or "Input string was not in a correct format" errors.
Edit 2019-12-10
After reading wallas-tg's answer below, I have tried the following in the daily build pipeline:
trigger:
branches:
include:
- '*'
exclude:
- 'refs/tags/*'
This works, but does not do what I would like:
Pushing only a tag triggers the correct pipeline and not the one for daily builds
Pushing a commit without tags triggers the daily build pipeline
Pushing a tagged commit triggers both pipelines: the daily build pipeline gets triggered by the commit, and the other one by the tag; my desired behavior in this case would be that the daily build pipeline is not triggered.
#acasta69
I think that i found solution for your issue. I've been doing just the opposite scenario, build only features branches and exclude anything else.
For this purposes use this yml snippet on azure-pipelines.yml
resources:
repositories:
- repository: myNetProject
type: GitHub
connection: myGitHubConnection
source: wkrea/DockerHubImages
trigger:
batch: true
branches:
include:
- releases/*
exclude:
- '*'
paths:
exclude:
- README.md
I was be able to build on DevOps from
If this answer was useful for you, let me know commenting and rate my answer to find it more easy next time that anyone need help, because the DevOps Pipelines documentations it's really unclear and confusing at moment :'(
Here you can see checks for my last commit on releases branch
The syntax for build pipeline triggers is documented on this page.
Regarding what is exposed in the question, a couple of details are worth highlighting:
There is a default implicit trigger that includes all branches and is overwritten by any user-defined trigger. Thus, it is not possible to specify a trigger that only excludes something: doing that would end up in nothing being included, and the trigger would never fire.
This explains why the first code snippet shown in the question does not trigger anything.
When you specify a trigger, it replaces the default implicit trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline. Includes are processed first, and then excludes are removed from that list. If you specify an exclude but don't specify any includes, nothing will trigger.
The default implicit trigger looks like this (note the comment in last line, which explains the error produced by the second code snippet in the question):
trigger:
branches:
include:
- '*' # must quote since "*" is a YAML reserved character; we want a string
Summarizing, a correct way to do exclude tagged commits from triggering the pipeline should be the one shown in the edited part of the question:
trigger:
branches:
include:
- '*'
exclude:
- 'refs/tags/*'
Or, which is equivalent:
trigger:
branches:
include:
- '*'
tags:
exclude:
- '*'
However, this does not obtain the desired effect. The following happens instead:
Pushing a commit without tags triggers the pipeline
Pushing only a tag does not trigger the pipeline
Pushing a tagged commit still triggers the pipeline
A final feedback received from Azure DevOps support clarifies that there is no way at the moment to obtain the desired behaviour:
Basically there is no way right now to prevent builds from being triggered if the tags are committed along with the branch changes and the CI on branch changes are enabled on the pipeline. There are couple of options you can use to prevent triggering the build on new tags:
Check-in the tags separately than the branch changes.
Add "[skip ci]" to your commit message to skip triggering the build on that particular commit.
None of the two options fit well to the original request. #1 is already working as intended, i.e. it does not trigger the build unless tags are explicitly included in triggers, which is only a part of the original request. #2 has the desired behaviour, but it requires a specific commit text and would force any user of the pipeline to be aware of its internals.
The workaround that I found in the meantime, as mentioned in a comment, was to use only one pipeline, that is always triggered by any commit, whether tagged or not, and detect the use of tags with dedicated scripts to activate specific pipeline steps when required.