I'm trying to enable/disable multiple pipelines based on a condition, would like to create a pipeline that takes the parameter from the user and updates all the other pipelines.
I've found these below documents from Microsoft
https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/pipelines?view=azure-devops-rest-6.0
https://learn.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines?view=azure-cli-latest
but I'm not able to find anything for enabling/disabling a pipeline, is there any way of doing this in any other ways?
I'm not able to find anything for enabling/disabling a pipeline, is there any way of doing this in any other ways?
You can use the REST API Definitions - Update to enable or disable pipelines.
PUT https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.0
For its request body, you need to get the definition of the build using the GET REST API first:
GET https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.0
Use the response body of GET REST API as the request body of PUT REST API. And then modify the value of queueStatus according to your requirements.
If you want to enable the pipeline, set the value of queueStatus to enabled; If you want to disable the pipeline, set the value of queueStatus to disabled.
Related
I'm trying to trigger a job from one Jenkins (A) on another one (B). I've installed 2 plugins:
Parameterized Remote Trigger
Build Token Root
My issue is, that I'm able to trigger build on Jenkins (B) using for example curl and token only, which means the Build Token Root plugin is working as expected, but Parameterized Remote Trigger seems to don't respect this.
I probably should mention that I've tried different auth options, Trust All certs, etc.
My Jenkins (A) config:
Logs are the same with and without Build Token Root support enabled.
Logs I'm getting:
I was able to get this working by allowing Anonymous users Overall Read and Job Read access. It appears this is necessary because the Parameterized Remote Trigger plugin attempts to call additional APIs apart from just the /build and /buildWithParameters and those calls are the ones that fail.
It makes sense that, in order to have the default blocking capability, you need to call additional APIs to poll, but even setting blockBuildUntilComplete : false did not fix the issue. Considering that Parameterized Remote Trigger plugin plainly says it "plays well" with the Build Token plugin in its documentation, it really is not an easy feat to make them work together.
In my opinion, using the two together isn't an ideal solution because of the necessity for allowing unauthenticated users to browse your jenkins instance via the ui - I suspect you could (although I haven't tried it) get an API Token for a user with only Overall Read and Job Read access instead of giving all Anonymous Users the rights, but this includes the overhead of managing a user and an API Token, which defeats our primary motivation to use the Build Token plugin in the first place.
I Currently have a Pipeline built in Jenkins to run my newman Test Cases. So the definition for it is in three steps
Call the Async Test cases.
Register a Webhook and Wait for it to respond back to continue forward.
Call the remaining Test cases.
I'm using the existing "Webhook Step Plugin" to register and wait for my Webhook in Jenkins.
Definition:
Pipeline Definition
Problem:
This resgisterWebhook() method is returning a random URL everytime because it is using the UUID logic to generate a random token. And since its random everytime, my external System cannot know it.
Question:
So i'm looking for a way, where the hook URL will be constant always, so that it can be hardcoded in my external System and called once the Async Operation is completed.
Don't use the webhook step, either use the webhook trigger plugin, or use the generic webhook trigger inside pipeline. (these may be the same thing - I may have just stuttered. Sorry if so!).
Anyway, that lets you set up a static URL you can use to trigger builds.
Jenkins. How to get Trigger builds remotely data from POST BODY
Quay.io (private docker containers registry) has notification about build status through Webhook POST, data is in body. I tried to google and read Jenkins docs, but found only how to read parameters from URL.
I found a plugin (Generic Webhook Trigger), which is capable to do it partially. It is able to work only with one link (http://{JENKINS_URL}/generic-webhook-trigger/invoke). And to start different jobs i need to use regexp.
At the same time i need to set up minimum 3 notifications on quay.io and a lot of webhooks from different services. Maybe somebody knows how to set up in Jenkins such stuff:
Create route like {JENKINS_URL}/jobName/ …
Take whole parameters and write it down into $POST_DATA variable.
Execute script with $POST_DATA parameter.
Another manipulations i’m able to do myself in script.
If you have a job like some-job-name.
Question 1:
Check the "Trigger builds remotely". Specify a token, like some-job-name.
Point the webhook to http://{JENKINS_URL}/generic-webhook-trigger/invoke?token=some-job-name .
Now this will be the only job triggered from this request.
Question 2:
Set the json-path to just $ and it will evaluate to the entire post data. Use any variable like variable.
Question 3:
Just use the variable from 2 like $variable.
I am looking for a method to remotely update a build parameter for a Jenkins jobs after the job has started (or even after the job has completed perhaps).
Looking over the API docs, I have seen plenty of examples of doing a GET to retrieve information, and some examples of doing a POST to trigger build configurations to run.
I'm struggling to find any examples or information on whether it's possible to set information such as a parameter via API, e.g. using POST.
Is there a simple way of accessing the Jenkins API key (as described by Authenticating scripted clients) of the user that invoked the script? I'm looking to pass it into the build script so that it can perform some maintenance operations back on Jenkins.
Since I never found one, I can say that it's safe to say that (as of May '12, at least) there isn't one.