I have the following requirement. I have a Jenkins pipeline which I want to be triggered once a Bitbucket pipeline has been finished with success. The problem is that I need to pass also some params and I don't want to use an asynchronous process like Bitbucket webhooks.
Is it another way to trigger the Jenkins pipeline automatically receiving multiple params?
I want to mention that these params can be retrieved also from the AWS resources created by that Bitbucket pipeline.
I faced the same issue, but i found a solution using Additional Behaviours
from git plugin.
Using Polling ignores commits with certain messages, which allow you to:
ignore any revisions committed with message matched to the regular expression pattern when determining if a build needs to be triggered.
and am using [skip ci] int the commit message, to commit changes after Bit-bucket pipeline finished.
so i used a custom regex ^(?!.*\[skip ci\]).*$ to skip any commit not including the tag.
which will result to only trigger Jenkins once the pipeline finished.
Related
I need to build a Gitlab CI pipeline manually but not using latest of my master branch, but using a specific commitID.
I have tried running pipeline manually by using variable as below and passing its value but of no use.
Input variable key: CI_COMMIT_SHA
At the time of this writing, GitLab only supports branch/tag pipelines, merge request pipelines and scheduled pipelines. You can't run a GitLab pipeline for a specific commit, since the same commit may belong to multiple branches.
To do what you want, you need to create a branch from the commit you want to run the pipeline for. Then you can run the manual pipeline on that branch.
See this answer for step-by-step instructions on how to create a branch from a commit directly in the GitLab UI.
Use the existing (created by Gitlab CI) workspace to run the .gitlab-ci.yml and from there checkout the code again in a different directory using commitID, and perform all the operations there.
I just setup CI/CD for a GitHub repo.
The CI build which validates a pull request is setup up as GitHub Action.
The CD build (which should run after the pull request was merged) is setup using Azure Pipelines as i would like to use the artifacts generated as a trigger for a Release Pipeline using Azure Pipelines as well.
The only thing that's still bugging me is, that the CD Build is also triggering automatically for a pull request and i can't figure out where i can configure those checks.
The checks currently running when a pull request is created are the following:
I want to get rid of the Continous Delivery Build here.
I tried to configure the branch protection rules but this has no effect:
On the Azure Pipeline side i completely disabled the triggers:
But this also has no visible effect to me.
I tested Disable pull request validation in the Triggers of the azure devops pipeline. On my side, it works well, and the build pipeline validation check is not displayed in the github pull request.
You can first check whether the pipeline source repo that you set the "Disable pull request validation" option corresponds to the github repo that created the pull request. Then try a few more times, it is possible that the settings are not applied immediately.
In addition, as workaround you can opt out of pull request validation entirely by specifying pr: none in yaml. Please refer to this official document.
# no PR triggers
pr: none
I want to use the Gitlab api to create a commit to create several commits on a single branch, but I'm worried that Gitlab's CI will activate for each commit.
Will creating a commit using the repository/commits api trigger CI? If not, is there a way to manually trigger CI when I'm done? If it will, is there a way to supress it, like git push -o ci.skip (see here)
A commit created by an API call is treated as a regular git commit. This means it will trigger your CI if it matches the conditions of your .gitlab-ci.yml file.
If you want to skip the CI add [skip ci] to your commit message.
We have an app (let’s call it the main repo) on GitLab CE, that has a production build & deploy pipeline, which is only triggered when a tag is deployed. This is achieved in .gitlab-ci.yml via:
only:
- /^v.*$/
except:
- branches
We also have two other (let’s call them side) repositories (e.g. translations and utils). What I’d like to achieve is to rerun the latest (semver) tag’s pipeline of main, when either of those other side repositories’ master branches receives a push. A small detail is that one of the repositories is on GitHub, but I’d be happy to get them working on GitLab first and then work from there.
I presume I’d need to use the GitLab API to trigger the pipeline. What I’ve currently set up for the side repo on GitLab is a webhook integration for push events:
https://gitlab.com/api/v4/projects/{{ID}}/ref/master/trigger/pipeline?token={{TOKEN}}, where ID is the ID of the main project and TOKEN a deploy token for it.
However, this will only trigger a master pipeline for our main repo. How could I get this to (also) rerun the latest tag’s pipeline (or the latest tagged pipeline)?
Secondly, how would I go about triggering this on GitHub?
Either you can create new pipeline specifying ref which can be branches or tags, so in this case you need to know the exact tag value https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline
Or you can retry already the executed pipeline by providing its id which you can get from https://docs.gitlab.com/ee/api/pipelines.html#list-project-pipelines by sorting by id and filtering by ref but it'll give you the last pipeline with a tag /^v.*$/ which may not match with the specific version you need.
I have a buildbot server and Gitlab. I could not figure out, to trigger builds whenever a merge request is opened on Gitlab. The purpose should be, that buildbot writes a comment back to the merge request whenever a build succeeds or fails (where as the build is done on the merge request + the upstream branch).
Any hints how to trigger that?
Thanks!
The Gitlab team actually merged some stuff in to make it possible to fire web hooks whenever a merge request is opened or updated:
see https://github.com/gitlabhq/gitlabhq/pull/5881 and
https://github.com/gitlabhq/gitlabhq/issues/1137
You could implement a service like the one for GitLab CI. This actually posts back to the merge-request whether GitLab CI passed or failed the test-suite.
I implemented one and am contributing it back to the buildbot project, see https://github.com/buildbot/buildbot/pull/1820
It uses webhooks and posts comments back to the merge request to show build status.