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.
Related
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.
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 have n features branch that will MR and merge into a develop branch.
I have a pipeline with 3 stages:
stages:
- feature-push
- develop-mr-retag
- develop-mr-rollout
feature-push runs on any push to a feature branch (not the develop branch we are merging into). It will test, build, and push an app in a docker image tagged with the name of the feature branch.
The latter two stages should run on commits to a branch develop after a merge request is approved and merged (assuming the source branch passed the feature-push stage). It needs to rollout the new image to some k8s pods, and it needs the name of the source branch to find the correct image.
I want to use ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME} for this, but I don't think that variable exists for pipelines run after a merge, only on merge_requests pipelines. These seem to be triggered before an MR is approved, which I don't want as this is a deployment.
Is this possible or should I find a different approach?
**Edit: ** To clarify, I need to run my docker build before MR, to know it can build successfully. I don't want to just throw away that build if it's the one that gets merged, so that's why I want to build/push before MR, and deploy the previously built image after MR.
I'm looking for the same.
For the moment, I parse the commit title of the mergecommit to extract the source branch, and I check that the branch found really exist. Here is the relevant code :
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME=$(sed -r "s/^Merge branch '(.*)' into .*/\1/i"<<<$CI_COMMIT_TITLE)
if [ $(git ls-remote --heads ${CI_REPOSITORY_URL} $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME | wc -l ) -ne 1 ]; then echo "Can't find source branche ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME})" && exit 1; fi
But if the default commit title is modified by anybody, this will not work.
I'm configuring my Circleci config right now to try to deploy a staging build for every new branch and then sends a message to my slack team with the link to the staging demo.
I've done the sending message to slack part, but now CircleCI sends a message to slack every time I push. I would like to limit that to happen only once for a specific branch. I know there's CIRCLE_BRANCH env that I can use to identify the current branch, but how do I save that variable in some kind of cache so I can run a conditional check on that variable to avoid running the same command twice?
I've checked the CircleCI docs and they offered cache on files but didn't mention anything about saving a variable as cache.
My config.yml file for CircleCI looks like this:
slackMessage:
docker:
- image: circleci/node
working_directory: ~/client
steps:
- attach_workspace:
at: ~/client
# - run: echo "$CIRCLE_BRANCH" > _branch_check
# - restore_cache:
# keys:
# - pr-{{ checksum "_branch_check" }}
- run:
command: |
PR_NUMBER=${CIRCLE_PULL_REQUEST##*/}
# yolo=pr-`echo -n $CIRCLE_PULL_REQUEST | md5sum`
# if [ -f "$yolo" ]; then
# touch $yolo
curl -X POST <Slack API webhook curl url>
# fi
# - save_cache:
# key: pr-{{ checksum "_branch_check" }}
# paths:
# - pr-{{ checksum "_branch_check" }}
The lines that are commented are the saving to cache part. With these lines commented CircleCI would send a message to Slack on every push. Without the comment the expected behavior is for CircleCI to send the slack message only once for each branch name.
Very cool question. I'll share some ideas that might work.
So, is the staging site URL created based on the branch name? Would it always be generated the same way?
If so, on CircleCI I would check for the existence of the staging URL first. If it's there, it was already created, which means this branch has already posted to Slack, and the execution can end right there.
Another idea would be to touch .staging-created a file into the FS, and save it into CircleCI cache using the branch name ({{ .Branch }}) as part of the key. Then, before sending the message to Slack, check for that file after cache has been restored.