I want to check and validate if the merge to master was a good one or bad one so I want to trigger the pipeline to check the merge requests after it is merged to a master branch.
Pipeline should trigger atomically once a PR is merged
pipeline should be successful if the merge is a good onw
pipeline should fail if the merge is bad
[New to DevOps] Any other solutions are likely appreciated!
Read thru the Bitbucket pipeline documentation https://support.atlassian.com/bitbucket-cloud/docs/get-started-with-bitbucket-pipelines/
Pipeline should trigger atomically once a PR is merged
It is possible to run a set pipeline when you do a merge.
pipeline should fail if the merge is bad
Any pipeline can be made to fail, if the step's scripts are made so they can return an error code if they run into issues. You just need to make the steps to check what could have gone wrong. Bitbucket PR page will tell you before you merge if there are conflicts.
Related
I currently have a gitlab ci pipeline that pushes commits to the branch the pipeline is running on to update code versions (using python-semantic-release). As far as I can tell, the later stages in my pipeline do not use this newly pushed code and instead a new pipeline is triggered for this commit. I am currently skipping the triggered pipeline using [skip ci]. I would like to be able to use the original CI pipeline to finish packaging the code and publishing documentation using the new commit. Is there anything I can do to update the commit that the current CI pipeline is running on or something?
I am not aware of changing the ref mid-pipeline.
You might try and experiment with downstream pipelines, especially the multi-project ones (even though would remain in the same project).
Those (downstream "multi-project" pipelines) are the ones which does not have to run under the same project, ref, and commit SHA as the upstream pipeline (as oppose to parent-child pipeline).
I would also push the code (after the python-semantic-release step) to a different branch, in order for your second pipeline to operate on that second branch, directly with the right code.
I have a Pipeline job that needs to run only after an MR has been merged to a certain branch (let’s assume it’s master).
This job is supposed to make an API call to send the name of the merged source branch.
The problem I’m encountering is that CI_MERGE_REQUEST_SOURCE_BRANCH_NAME will not be available on the Pipeline that runs right after the merge (since it’s not a merge request pipeline).
Is there a way (env var) to tell what was the branch that was just merged into master?
Many thanks in advance y’all!
Better you work with hashes not with the names.
Anyway I see two options:
In the pipeline for the merge request save the hash/name in an artifact. The subsequent pipeline can access this artifact an read the hash/name.
Run a independent pipeline and read the hash/name of the previous pipeline. To do this more secure you can add tags and read the previous pipeline only if it has the correct tag.
I am currently trying to implement a pipeline using Gitlab ci. I defined my pipeline in a gitlab-ci.yml file to run my jobs. I am working on pipeline where jobs are triggered by opened merge request. more specifically , non WIP and draft merge request. One of the most important condition is also that I want the job to be triggered and running when merge request changes state from WIP/draft to "ready".
Below is the closest way I found to do such thing.
integrationtest:
stage: integrationtest
only:
- merge_requests
except:
variables:
- $CI_MERGE_REQUEST_TITLE =~ /^WIP:.*/
Unfortunately, Now the only thing missing is indeed the pipeline being triggered when WIP state changes.
Any idea to bypass this problem is more than welcome.
Thank you in advance :)
There is an open issue for you exact use case. There is a workaround with webhook integration mentioned in the last comment of this issue, maybe this will help you.
Back in the days I've seen on a demo (can't recall now where) where after every push, the Gitlab CI automatically created a pipeline for this commit in an appropriate branch, but without running it automatically.
This allowed user to run pipeline on any branch without having to manually select branch from "new pipeline" button.
Can't find such information in the documentation. Perhaps it was a hack but nonetheless it worked.
New to Gitlab CI/CD.
What is the proper construct to use in my .gitlab-ci.yml file to ensure that my validation job runs only when a "real" checkin happens?
What I mean is, I observe that the moment I create a merge request, say—which of course creates a new branch—the CI/CD process runs. That is, the branch creation itself, despite the fact that no files have changed, causes the .gitlab-ci.yml file to be processed and pipelines to be kicked off.
Ideally I'd only want this sort of thing to happen when there is actually a change to a file, or a file addition, etc.—in common-sense terms, I don't want CI/CD running on silly operations that don't actually really change the state of the software under development.
I'm passably familiar with except and only, but these don't seem to be able to limit things the way I want. Am I missing a fundamental category or recipe?
I'm afraid what you ask is not possible within Gitlab CI.
There could be a way to use the CI_COMMIT_SHA predefined variable since that will be the same in your new branch compared to your source branch.
Still, the pipeline will run before it can determine or compare SHA's in a custom script or condition.
Gitlab runs pipelines for branches or tags, not commits. Pushing to a repo triggers a pipeline, branching is in fact pushing a change to the repo.