I am using this syntax to trigger workflow at the scheduled time only for prod branch.
on:
schedule:
- cron: "11 0 * * SAT"
branches:
- prod
But when I push the code it shows a syntax error:
You have an error in your yaml syntax on line 4
Any inputs? Does the schedule work with "branches" option?
You are trying to create a job on schedule, if you want to checkout your code, you have to use
actions/checkout#v2
Check for this article How do I trigger a scheduled action on a specific branch?
branches prod make sense only when you use on push or on pull_request.
Related
I would like to execute a travis stage only on specific commit message (finally on a text tag in a commit message, but let's simplify for now).
Travis allows conditional execution using if statement (and I prefer to use that, because of the structure of my travis file). Travis documentation mentions 2 variables that could be used to get commit message:
commit_message and TRAVIS_COMMIT_MESSAGE
I tried using both of them. In these cases:
- stage: Deploy
if: commit_message = "deploy" AND type = push
- stage: Deploy
if: $TRAVIS_COMMIT_MESSAGE = "deploy" AND type = push
the stage is executed always, no matter what is the content of the commit message.
In that case:
- stage: Deploy
if: env(TRAVIS_COMMIT_MESSAGE) = "deploy" AND type = push
The stage is never executed, no matter what is the content of the commit message.
I also tried adding conditions: v1 in the root of the .travis file, but with no effect.
It seems like comparison operator is not working as expected (especially in first two cases - how can it always be true if strings are not equal??).
How to right write job in .gitlab-ci.yml when it run only in merge requests?
test_c:
stage: test
script:
- echo "This job tests something. It will only run when all jobs in the"
- echo "build stage are complete."
only:
- merge_requests
This job not run in merge request, but not run and in commint in master or develop.
Gitlab documentation recommends using 'rules' instead of 'only'. You can accomplish only merge_requests by doing the following:
test_c:
stage: test
script:
- echo "This job tests something. It will only run when all jobs in the"
- echo "build stage are complete."
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
https://docs.gitlab.com/ee/ci/yaml/#workflowrules
You can use the workflow to control pipeline creation. Define this keyword at the top level, with a single rules. This example shows that the pipeline will only be executed when a new merge request is created, the last when is set to never to prevent pipelines from executing when a new branch is pushed to the server or for any other type of event.
workflow:
rules:
- if: $CI_MERGE_REQUEST_ID
when: always
- when: never
Notice
As mentioned in the Gitlab documentation
These pipelines are labeled as detached in the UI, and they do not have access to protected variables. Otherwise, these pipelines are the same as other pipelines.
If your intention is just not to run the job on specific branches, like master or dev, you may simply exclude them with except:
test_c:
(...)
except:
- master
- dev
Your code is correct, commit it to master before test your merge_request pipelines please.
I'm having a Gitlab CI/CD pipeline, and it works OK generally.
My problem is that my testing takes more than 10 minutes and it not stable (YET..) so occasionally randomly it fails on a minor test that I don't care for.
Generally, after retry, it works, but if I need an urgent deploy I need to wait another 10 minutes.
When we have an urgent bug, another 10 minutes is waaaay too much time, so I am looking for a way to force deploy even when the test failed.
I have the next pseudo ci yaml scenario that I'd failed to find a way to accomplish
stages:
- build
- test
- deploy
setup_and_build:
stage: build
script:
- build.sh
test_branch:
stage: test
script:
- test.sh
deploy:
stage: deploy
script:
- deploy.sh
only:
- master
I'm looking for a way to deploy manually if the test phase failed.
but if I add when: manual to the deploy, then deploy never happens automatically.
so a flag like when: auto_or_manual_on_previous_fail will be great.
currently, there is no such flag in Gitlab ci.
Do you have any idea for a workaround or a way to implement it?
Another approach would be to skip the test in case of an emergency release.
For that, follow "Skipping Tests in GitLab CI" from Andi Scharfstein, and:
add "skip test" in the commit message triggering that emergency release
check a variable on the test stage
That is:
.test-template: &test-template
stage: tests
except:
variables:
- $CI_COMMIT_MESSAGE =~ /\[skip[ _-]tests?\]/i
- $SKIP_TESTS
As you can see above, we also included the variable $SKIP_TESTS in the except block of the template.
This is helpful when triggering pipelines manually from GitLab’s web interface.
Here’s an example:
It's possible to control the job attribute of your deploy job by leveraging parent-child pipelines (gitlab 12.7 and above). This will let you decide if you want the job in the child pipeline to run as manual, or always
Essentially, you will need to have a .gitlab-ci.yml with:
stages:
- build
- test
- child-deploy
child-deploy stage will be used to run the child pipeline, in which the deploy job will run with the desired attribute.
Your test could generate as artifact the code for deploy section. For example, in the after_script section of your test, you can check the value of CI_JOB_STATUS builtin variable to decide if you want to write the child job to run as manual or always:
my_test:
stage: test
script:
- echo "testing, exit 0 on success, exit 1 on failure"
after_script:
- if [ "$CI_JOB_STATUS" == "success" ]; then WHEN=always; else WHEN=manual; fi
- |
cat << 'EOF' > deploy.yml
stages:
- deploy
my_deploy:
stage: deploy
rules:
- when: $WHEN
script:
- echo "deploying"
EOF
artifacts:
when: always
paths:
- deploy.yml
Note that variable expension is disabled in the heredoc section, by the use of single quoted 'EOF'. If you need variable expension, remember to escape the $ of $WHEN.
Finally, you can trigger the child pipeline with deploy.yml
gen_deploy:
stage: child-deploy
when: always
trigger:
include:
- artifact: deploy.yml
job: my_test
strategy: depend
I want to update my yml file to ignore commits from certain users. Is this possible? Is there a similar solution? Ideally I wouldn't even want to trigger the build in the first place.
Pseudo code example of yml file (ignore syntax, I'm just showcasing what I'm trying to do)
user: git show -s --format='%ae' $BITBUCKET_COMMIT
unwantedUser: "person#mail.com"
pipelines:
tags:
'**' && user != unwantedUser: # any tags by wanted users
- step:
script:
(...)
What would be the actual syntax to achieve that?
I ended up including the [skip ci] string in my commit messages to avoid triggering the pipeline.
From the documentation:
Can I commit without triggering the pipeline? Yes. If you don't want
to run a pipeline on a commit that would normally trigger one, you can
include [skip ci] or [ci skip] anywhere in your commit message of the
HEAD commit. Any commits that include [skip ci] or [ci skip] in the
message are ignored by Pipelines.
Alternatively, if you want to trigger pipeline manualy you can use 'custom' tag.
From the documentation
pipelines:
custom: # Pipelines that can only be triggered manually
sonar:
- step:
script:
- echo "Manual triggers for Sonar are awesome!"
Custom pipelines do not run automatically on a commit to a branch. You can run a pipeline with commits view page or branches view page.
In the circleci version 1 config, there was the option to specify owner as an option in a deployment. An example from the circleci docs ( https://circleci.com/docs/1.0/configuration/ ) with owner: circleci being the key line:
deployment:
master:
branch: master
owner: circleci
commands:
- ./deploy_master.sh
In version 2 of the config, there is the ability to use filters and tags to specify which branches are built, but I have yet to find (in the docs, or on the interwebs) anything that gives me the same capability.
What I'm trying to achieve is run build and test steps on forks, but only run the deploy steps if the repository owner is the main repo. Quite often people fork using the same branch name - in this case master - so having a build fail due to an inability to deploy is counter-intuitive, especially as I would like to use a protected branch in git and only merge commits based on a successful build in a pull request.
I realise we could move to only running builds based on tags being present, but nothing is stopping somebody with a fork also creating a tag in their fork, which puts us back at square one.
Is anybody aware of how to specify the owner of a repo in the version 2 config?
An example from the version 2 config document ( https://circleci.com/docs/2.0/workflows/ ) in case it helps jog somebodies memory:
workflows:
version: 2
un-tagged-build:
jobs:
- build:
filters:
tags:
ignore: /^v.*/
tagged-build:
jobs:
- build:
filters:
branches:
ignore: /.*/
tags:
only: /^v.*/
disclaimer: Developer Evangelist at CircleCI
That feature is not available on CircleCI 2.0. You can request it here.
As an alternative, you might be able to look for the branch name, say master, as well as the CIRCLE_PR_NUMBER environment variable. If that variable has any value, then it's a fork of master and you shouldn't deploy.