I am using below API to get the latest deployment status(If any release going on) from 3 pipeline's before starting an deployment in each pipeline.
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=100&deploymentStatus=inProgress"
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=101&deploymentStatus=inProgress"
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=102&deploymentStatus=inProgress"
Based on count I am deciding whether the any run going on in pipeline if count > 0. I am working on logic where if any deployment going on in other pipeline then Deployment should wait for other to finish since all are deploying to same environment.
The status checking task also is in progress so it is going to infinite loop to wait if task is running. Is there any way to achieve this.
Based on your requirement, you need to check the Deployment status of the release pipeline.
To alleviate your issue, I suggest that you can add an additional stage to each release pipeline and then you can add the check deployment status in the new stage.
Refer to my steps:
Add a new stage before the deployment stage and add the status check steps.
In the Rest API, you can add the definitionEnvironmentId parameter in the URL to check the specify stage.
For example:
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=102&deploymentStatus=inProgress&definitionEnvironmentId=xx"
In this case, you can separate the check status step and the deployment process.
For more detailed info, you can refer to this doc: Deployments - List
Related
I integrated Bitbucket with Cloudbees, having the following workflow: everytime an user creates a Pull Request, having as target develop branch, a multi-branch pipeline in cloudbees will cluster the pull request (e.g. PR-34) and it will trigger the first build (#1). If it passes, then everything is ok and bitbucket will show the build status as "passed".
However, if the build fails, it means that the user should trigger another one on the same pull request (PR-34 #2). If the second build passes, I expect to have the build status as "passed" but I get "1 build failed", due to the first build and no matter how many passed builds I will have in the future, the status will always remain as failed if at least one of the builds failed.
So, in order to resume the problem I need help on those following topics:
How should I configure bitbucket pull request status to show me the result of the latest build?
How should I constrain the merge checks so that users will be able to merge a pull request only if the latest build passed? Note: the check "Minimum successful builds" will not work since the behavior is the following: "If there are more builds than specified, they are all required to be successful in order to merge the pull request."
How to prevent the launch of the build code branch, if the build code from a branch is already in progress?
Build runs through API from JIRA Automation (Send Webhook Request) to:
http://teamcity.url/app/rest/buildQueue?buildTypeId=<buildTypeId>
Request Body:
<build branchName="{{issue.fields.branch}}">
<buildType id="<buildTypeId>"/>
</build>
Problem: since the JIRA does not know anything about whether the build is running or not on the TeamCity, the JIRA starts the build again if rule was executed
TL;DR
I checked and it works
Just create the base configuration which you want to run. Let's say A
Create the configuration B which depends from A as Slapshot dependency with params
Do not run new build if there is a suitable one - checked
Only use successful builds from suitable ones - checked
Run build on the same agent - unchecked
Make build start of faild - both
How it works?
You will trigger the configuration B. B depends from A. B checked that the A already has a build with some branch and commit, so, no need to run one more, so let's finish.
if A has a new commit then the B see that A has changes, so let's start a new Build A, wait for finish.
If A failed then B also will be failed.
p.s. now you should trigger B instead of A.
We're using TeamCity with the Sonar plugin. Is there a way to fail the TeamCity build if some metric (i.e. number of Blocker issues, amount of technical debt, etc.) increases within Sonar, or if it just fails the Quality Gate? I haven't found any documentation regarding this.
For now, the options available for this are
the Build Breaker Plugin (assuming Team City is compatible with the way this plugin woks)
adding a script step in your job (again, assuming TC supports it) to poll SQ in a loop for the completion of analysis report processing, then to grab the QG status and conditionally fail the build.
2018 EDIT
There is now non-blocking support for this within Jenkins Pipelines. More in the docs.
yes you can do it using powershell scripts .Call the sonar rest api for the project using metric and metric key .Compare the result with the project if the metric value dose not match the exit from the build.
I created a webhook in jenkins and connected it to github webhook & services.
I came upon the following issue When the build is completed, the pom.xml is updated with the version and tag . This triggers build job again and its goes into a loop until, I manually stop it .
I have set the build trigger to "Build when a change is pushed to GitHub"
I would like to find out how to stop the build trigger when the pom.xml is updated only as part of the build?
In the source code management job configuration section add Additional Behaviors and select Polling ignores commits from certain users and provide the user name your Jenkins job uses to checkin pom.xml. You can also use Polling ignores commits in certain paths and provide path to pom.xml.
I'd suggest not committing the version update to the master branch but create a separate tag every time. Something like this:
v1 v2 v3
/ / /
--A----B----C (master)
I got this approach from Real-World Strategies for Continuous Delivery with Maven and Jenkins video (corresponding slides) - it contains other tips on setting up build pipelines with Maven as well.
I have a Build & Deploy Pipeline in Bluemix, I would like to create a condition where, if the build fails, it will automatically assign a defect (i.e., work item in the "Track & Plan" page) to whoever delivered the very latest change (or just assign to the main owner of the App/Project), also, if the build is completed successfully, I would like to tag it.
Tagging is ok, that's general GIT knowledge, I just wanted to solve 2 Problems with that plan:
How do we trigger a specific subsequent Stage in the pipeline if the current build fails/passes?
How do I create a work item from the pipeline? Do I need to create a separate GIT repo and build some sort of API package that allows me to invoke a mechanism that creates the ticket?
I guess I'm going too maverick with this Pipeline, please share your thoughts.
As of right now you can not create a work item from the pipeline. That is a great feature improvement and I can take it back to the team.
For your question about triggering a stage if something passes or fails... The way it works now only the next stage will be triggered if the previous is successful. The pipeline is based on Jenkins and Jenkins doesn't allow you to trigger a specific job if a job passes or fails. You would want to detect the pass or fail in your stage and do your logic based on that.