The workflow configuration in my .circleci/config.yml file looks like this:
workflows:
version: 2
test-and-deploy-if-tagged:
jobs:
- build-and-test:
filters:
tags:
only: /.*/
- deploy-to-qa:
filters:
tags:
only: /^deploy.*/
branches:
ignore: /.*/
The deploy-to-qa workflow includes:
deploy-to-qa:
requires:
- build-and-test
On a regular master commit the build-and-test workflow runs. This is what I want. š
When I'm ready to cut a build, Iā¦
make a new commit to bump the version number
tag the new commit (e.g. deploy-build-123)
After I push the new commit and tag, CircleCI runs build-and-test twice and deploy-to-qa once.
How can I configure it so a tagged release runs build-and-test only once, and if it passes, then run deploy-to-qa?
What's happening is exactly what's supposed to happen.
After I push the new commit and tag
The commit runs build-and-test as you wanted and the tag runs both, as you wanted.
Related
This is an extract of my config.yml file for CircleCi:
workflows:
version: 2
deploy:
when: << pipeline.parameters.run_workflow_deploy >>
jobs:
- deploy:
filters:
branches:
only:
- master
So I want to trigger my "deploy" job only on API calling. It works very well.
But CircleCi triggers automatically the workflow when some changes on the master branch, and here you are the message on CircleCi backoffice:
How avoid this automatic trigger from CircleCi?
Workflows on CircleCI are triggered on every git push by default. From documentation -
By default, CircleCI automatically builds a project whenever you push changes to a version control system (VCS).
You can override this using the [skip ci] tag in the commit. See skip-build documentation
don't know if you are stil looking for an answer but... I managed to do it using parameters.
You create your branch parameter in your config.yml file:
version: 2.1
parameters:
git-branch:
default: non-existing-branch
type: string
and add a filter on the workflow job:
filters:
branches:
only:
- << pipeline.parameters.git-branch >>
So, the pipeline will not start on any commits, since it defaults to the non-existing-branch.
But then, you can pass the parameter in your API in the body.
"parameters": {
"branch-name": "develop"
}
This will actually trigger the pipeline to start correctly.
You can add default values for your parameters as follows:
parameters:
run_workflow_deploy:
default: false
type: boolean
You could also configure your logical statement (at the workflow or step level) using the built-in pipeline.trigger_source pipeline value (https://circleci.com/docs/pipeline-variables/#pipeline-values).
I'm trying to create two different actions within travis.ci. The first action is to execute a script on every push on every branch. This is currently working as desired. The second is to trigger a different script only when git push origin --tags. In short:
Execute script1 always (currently working)
Execute script2 when tags are pushed
Here is what I'm trying:
language: python
python:
- 3.7
matrix:
include:
- python: 3.7
sudo: true
install:
- pip install -r requirements.txt
script: # Always want this to happen
- invoke package
branches:
only:
- master
- /^x\/.*/
deploy: # Want this to occur on git push origin --tags
provider: script
script: invoke release
on:
tags: true
The deploy section is not being triggered, and I can find no evidence of the invoke release script being invoked.
Update:
It may be due to the way I'm pushing tags..? I'm seeing this log in travis now:
Skipping a deployment with the script provider because this is not a tagged commit
Solved it from this github issue. Changed the deploy section to this:
deploy:
provider: script
script: invoke release
on:
tags: true
all_branches: true
but had to remove the branches section. Deployment script was invoked, nonetheless.
What I want by default is for my branch to build, then wait for approval to deploy to dev. However, if I push to the dev branch, that should deploy without approval.
I have the following workflow:
workflows:
version: 2
build:
jobs:
- build
- approve-dev:
type: approval
requires:
- build
filters:
branches:
ignore: dev
- deploy-dev:
requires:
- approve-dev
The problem is that when the approve-dev job is skipped, the deploy-dev job loses its requirement, so the only possible step is build.
Is there a way around this?
I have worked out a way to do this, but it's quite verbose, basically you duplicate the workflow at that point, with one copy only for that branch, and one copy which ignores that branch, like so:
workflows:
version: 2
build:
jobs:
- build
- approve-dev:
type: approval
requires:
- build
filters:
branches:
ignore: dev
- deploy-dev:
requires:
- approve-dev
- deploy-dev-auto:
requires:
- build
filters:
branches:
only: dev
Using templates (<<deploy-dev-defaults: &deploy-dev-defaults) to define the tasks means you don't have to rewrite the job, just specify it twice with the two different names.
I am able to generate build trigger url and able to call build operation via Gitlab Web hook.
But the build operation is calling in each commit irrespective of any branch. But I want to trigger build operation for a specific branch commit. Means want to execute build only if any code pushed to a specific branch.
In Gitlab yaml you can specify each job to trigger on certain branches or excluding branches
https://docs.gitlab.com/ee/ci/yaml/#only-and-except
job_name:
script:
- rake spec
- coverage
stage: test
only:
- master
tags:
- ruby
- postgres
allow_failure: true
The above yaml would only execute on master
We are wondering whether there is any way to add filters to Travis matrix items. In our particular case, we wish to run certain jobs only on specific branches.
The following example would be an ideal way for configuring this scenario, however it doesn't seem to work:
matrix:
include:
- env: BUILD_TYPE=release
branches:
only:
- master
- env: BUILD_TYPE=ci
branches:
only:
- develop
As a workaround, we can exit from the build script immediately by checking the appropriate env vars (TRAVIS_BRANCH), but it is very far from ideal as launching the slave machine and cloning the repo takes a considerable amount of time.
You can now achieve this with the beta feature Conditional Build Stages
jobs:
include:
- stage: release
if: branch = master
env: BUILD_TYPE=release
- stage: ci
if: branch = develop
env: BUILD_TYPE=ci