Where should the bitbucket-pipelines.yml pushed to with a development and master branch? - bitbucket-pipelines

I have a development and a master branch. I pushed the bitbucket-pipeline.yml to the master branch and realized, that want to run my pipeline on the develop branch. Is it best practice to to commit it first on the development branch?

If you have bitbucket-pipelines.yml in a branch - then the file will be used for pipelines when you commit something to this branch, if you create a PR then the file from the first branch will be used (the same as commit).
The best practice is to have the file in every branch with a config that shares logic for all branches / tags / pull requests and if you need different rules for different branches - simply specify them in the bitbucket-pipelines.yml.
this file I have in every branch:
image: satantime/puppeteer-node:12.16.1-buster
pipelines:
default:
- step: &Preparation
- step: &Manual
- step: &BuildAOT
- step: &Lint
- step: &CodeStyle
- step: &LintTs
- step: &LintCss
- step: &UT
- step: &E2E
- step: &BuildDocker
pull-requests:
'**':
- step: *Preparation
- step: *Manual
- parallel:
- step: *CodeStyle
- step: *Lint
- step: *BuildAOT
- parallel:
- step: *UT
- step: *E2E
- step: *BuildDocker
branches:
'**': # <- rules for all branches
- step: *Preparation
- step: *BuildDocker
'master': # <- rules for the master branch
- step: *Preparation
- step: *UT
- step: *E2E
- step: *BuildDocker

Related

Specify build branch based on branch used in triggering pipeline Azure Devops

Say I have two pipelines: PL1 and PL2 and that PL2 is triggered by PL1. Say I ran PL1 on the master branch, I want PL2 to also get triggered for the master branch. When PL1 is triggered on another branch, like releases/X.X.X I want PL2 to also be triggered on the releases/X.X.X branch. Can I do that? Right now PL2 is always using master when it gets triggered
I tried to replicate the scenario.
First pipeline:
trigger:
- none
stages:
- stage: first
jobs:
- job: firstJob
continueOnError: false
steps:
- bash: echo "first from test branch"
Second Pipeline:
resources:
pipelines:
- pipeline: firstPipeline
source: first-pipeline
trigger:
branches:
include:
- ${Build.SourceBranch}
stages:
- stage: second
jobs:
- job: secondJob
steps:
- bash: echo Test-branch
I tested these from two different branches and each time the source code of second pipeline was picked up based on the first pipeline's branch.
PS: Both of my pipeline YAML are in same repository

Migrating azure-pipelines.yaml to separate repo, but running on code of other repo

Ultimately, I'm trying to do this:
Move azure-pipelines.yaml and associated templates out of the code repository (code-repo).
Move them into a separate dedicated repository (pipeline-repo).
Have the pipeline look at the config for the pipeline in pipeline-repo, but run the pipeline on the code in the code-repo.
I'm referring the following documentation:
Use other repositories: this one refers to "templates in other repositories," but I'm trying to remove any pipeline configs so the code-repo is just purely application code... and the Dockerfile.
Define a repositories resource
For testing, I have this simple test.yaml:
# Triggers when PR is created due to branch policies
trigger: none
resources:
repositories:
- repository: code-repo
type: git
name: code-repo
pool:
vmImage: 'ubuntu-latest'
stages:
- stage: Testing
displayName: Test stage
jobs:
- job: ParallelA
steps:
- bash: echo Hello from parallel job A
displayName: 'Run a one-line script'
When I create a PR on code-repo, it is triggering the pipeline, which is to say branch policies are configured to refer to that pipeline. I do get the print out the Hello from parallel job A print out.
But I don't see in the run logs it pulling code-repo.
I do see the following, however:
My actual PR pipeline would look something like this:
trigger: none
resources:
repositories:
- repository: code-repo
type: git
name: code-repo
variables:
- template: templates/variables.yaml
pool:
vmIMage: $(vmImageName)
stages:
- template: templates/build/buildStage.yaml
...
Testing that, it confirms that it isn't running on the code-repo PR, but the pipeline-repo so everything fails.
So it is unclear to me what I need to do from here to get the pipeline to run on the PR code from code-repo.
Suggestions?
Ok, I think I have it sorted out, at least some of my stages are now succeeding.
I came across this documentation which informed me of checkout.
So in addition to doing something like:
resources:
repositories:
- repository: code-repo
type: git
name: code-repo
Then you need to add a step called checkout like the following:
# Triggers when PR is created due to branch policies
trigger: none
resources:
repositories:
- repository: code-repo
type: git
name: code-repo
pool:
vmImage: 'ubuntu-latest'
stages:
- stage: Testing
displayName: Test stage
jobs:
- job: ParallelA
steps:
- checkout: code-repo
- task: task1
- task: task2
The checkout should set the context for the subsequent steps.

gitlab-ci.yml only on master branch

I have a gitlab-ci.yml file like this, and want to run it only on Branch Master. If there is a push into develop branch the Pipeline should NOT start.
I tried with 'only' keyword, but it shows an Error.
stages:
- info
- build
- test
- review
- cleanup
- deploy-dev
- integration-test
- deploy-test
- system-test
- deploy-production
only:
refs:
- master
To define a trigger rule for every stage you can use the workflow keyword, like this:
workflow:
rules:
- if: $CI_COMMIT_TAG
when: never
- if: $CI_COMMIT_BRANCH == 'master'
This has to be on the "root" of your yaml, as it is not part of any job in particular.
In the example above, I am telling the pipeline to avoid running when a repository tag is pushed and to run only when a commit is done in the master branch.
You can use this as a base and add other conditions to trigger the stages in the pipeline, the complete documentation on this matters can be found here: https://docs.gitlab.com/ee/ci/yaml/#workflow
I thin you have an indentation problem here.
It should be something like:
stages:
- job_1
- job_2
- ....
- job_n
job_1:
stage: job_1
....
only:
refs:
- master
job_2:
stage: job_2
....
only:
refs:
- master
....
You need to define the target branch for each stage.

How can I skip default pipeline on pull request?

In the project I am currently working on, I want to run the bitbucket pipeline according to the following rules.
Test and lint steps should run for each commit pushed to Branch.
The test-with-coverage and lint steps must be run for each record
opened with Pull Request.
The problem here is that if I push a commit to a branch that I have opened a pull request, the pipeline is triggered twice.
pipelines:
default:
- step: *lint
- step: *test
pull-requests:
'**':
- step: *lint
- step: *test-with-coverage
I looked for a way to skip default pipeline if a pull request exists, but I can't find it. I am open to suggestions and opinions.
pipelines:
default:
- step: *lint
- step: *test
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
pull-requests:
'**':
- step: *lint
- step: *test-with-coverage

Avoiding double-runs on merge requests - except merge_requests not working

I'm trying to make gitlab run 1 stage on merge_requests (and NOT on the push on the branch - so I only get ONE 1 for a merge_request)
AND make gitlab (actually the same - but I'm okay with having to define it twice if necessary) stage - on all branches (but NOT on merge_requests)..
I have tried this:
# Builds for all - except snapshots (branches) - as we would otherwise have 2x build run on merge_requests
build:
stage: build
only:
refs:
- merge_requests
- tags
artifacts:
paths:
- build/
script:
- ./build/build.sh ${CI_JOB_ID}
#EXACT copy of above - ONLY for snapshot builds
build-snapshot:
stage: build
only:
- branches
except:
- merge_requests
- test
artifacts:
paths:
- build/
script:
- ./build/build.sh ${CI_JOB_ID}
and the same with except: refs: .. (ie. advanced) - both yield the same result.. appearently gitlab does not see that there is a merge_request for the branch - so it runs it both for the branch, and for the merge_request :(
I have found the following issues which didn't help:
https://gitlab.com/gitlab-org/gitlab-ce/issues/13445

Resources