I am using jbpm version 6.5.0. I have requirement to call process through REST API and I am successful to start process with parameters.
I am testing it with postman. The thing is that there is also requirement of document attachments on starting by REST API, for that I have followed link (https://access.redhat.com/solutions/2567701 ) but unsuccessful to attach document in same process. The REST API URI provided in followed link is
http://server:port/kie-server/services/rest/server/containers/{containerName}/processes/{processId}/instances this is not working . I am stuck with containerName in the link .
Secondly, I have confusion i.e. there are 2 uri which starts process on is for sending parameters on RESTAPI and other is for document attachment RESTAPI. Will both of the REST API called by the application which want to start process .
I have check following to check containerName but unsuccessful.
http://localhost:8080/kie-server/services/rest/server/containers running successfully with out containers list
http://localhost:8080/kie-server/services/rest/server running successfully
http://localhost:8080/kie-server/services/rest/server/containers/%7Bid%7D Failure with msg Container id is not instantiated
Kindly provide me solution or steps any tutorial which have clear steps to achieve the task .
I am not sure whether it is too late to answer now. Here it is anyway.
For the classic employee evaluation process example of jBPM documentation, the HTTP request to create a process instance looks like the following. "evaluation_1.0" is the process container id and "evaluation" is the process id/name.
POST /kie-server/services/rest/server/containers/evaluation_1.0/processes/evaluation/instances HTTP/1.1
Host: localhost:8080
Authorization: Basic {basic auth token}
Content-Type: application/json
Content-Length: 43
{"initiator": "<jbpm user name>", "employee":"<employee name>"}
`
I have a large set of GCP Cloud Build Triggers that I invoke via a Cloud scheduler, all running fine.
Now I want to invoke these triggers by an external API call and pass them dynamic parameters that vary in values and number of parameters.
I was able to start a trigger by running an API request but any JSON parameters in the API request that I sent were ignored.
Google talks about substitution parameters at https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values. I define these variables in the cloudbuild.yaml file, however they were not propagated into my shell script from the API request.
I don't any errors with authentication or authorization, so security may not be an issue.
Is my idea supported at all or do I need to resort to another solution such as running a GKE cluster with containers that would expose its API (a very heavy-boxing solution).
We do something similar -- we migrated from Jenkins to GCB but for some people we still need a nicer "UI" to start builds / pass variables.
I got scripts from here and modified them to our own needs: https://medium.com/#nieldw/put-your-build-triggers-into-source-control-with-the-cloud-build-api-ed0c18d6fcac
Here is their REST API: https://cloud.google.com/cloud-build/docs/api/reference/rest/v1/projects.triggers/run
For the script below, keep in mind you need the trigger-id of what you want to run. (you can also get this by parsing the output of another REST API.)
TRIGGER_ID=1
# we need to specify ATLEAST the branch name or commit id (check after)
BRANCH_OR_SHA=$2
# check if branch_name or commit_sha
if [[ $BRANCH_OR_SHA =~ [0-9a-f]{5,40} ]]; then
# is COMMIT_HASH
COMMIT_SHA=$BRANCH_OR_SHA
BRANCH_OR_SHA="\"commitSha\": \"$COMMIT_SHA\""
else
# is BRANCH_NAME
BRANCH_OR_SHA="\"branchName\": \"$BRANCH_OR_SHA\""
fi
# This is the request we send to google so it knows what to build
# Here we're overriding some variables that we have already set in the default 'cloudbuild.yaml' file of the repo
cat <<EOF > request.json
{
"projectId": "$PROJECT_ID",
$BRANCH_OR_SHA,
"substitutions": {
"_MY_VAR_1": "my_value",
"_MY_VAR_2": "my_value_2"
}
}
EOF
# our curl post, we send 'request.json' with info, add our Token, and set the trigger_id
curl -X POST -T request.json -H "Authorization: Bearer $(gcloud config config-helper \
--format='value(credential.access_token)')" \
https://cloudbuild.googleapis.com/v1/projects/"$PROJECT_ID"/triggers/"$TRIGGER_ID":run
i'm using the following curl command to import the output.xml file into jira test execution key and receiving error as below. I'm sure the test execution key is existing in jira and the project id is also correct. Any pointers?
curl -H "Content-Type: multipart/form-data" -u userid:pass -F "file=#output.xml" "https://server/rest/raven/latest/import/execution/robot?projectKey=PROJKEY+and+testExecKey=TESTEXNKEY" -o error.txt
The error i receive is as below
The User "userid" does not have permission to create issues
Why does it try to create new issue while the issue already exists? And why does it say the user doesn't have access when the access is there?
You probably mean Xray add-on and you probably use the same request per their documentation. The problem seems to be with your parameter syntax. It should be .../robot/?projectKey=PROJKEY&testExecKey=TESTEXNKEY (i.e. & instead of +and+).
Plus I would explicitly specify it's a POST request: curl -X POST ....
But their error message is not clear, anyway. I don't have Xray available right now, but if you keep having troubles, I would recommend checking with their support.
I'm successfully able to use this to kick off a Jenkins Job:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
I can also get the consoleText from this job using:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/lastBuild/consoleText"
However, this doesn't scale if I run multiple jobs back to back. I've noticed that the first curl command has a return that includes:
Location: http://jenkins_srv:8080/queue/item/123/
I'm assuming that 123 is the job queue id.
My question is, if I queue jobs 121, 122, & 123 back to back, what do I use to check the status of job queue item 122? Also, what do I use to determine the actual build id that eventually resulted from job queue item 122?
I chose Kdawg's answer, because it helped lead me in the direction that I needed. Thank you!
I'm also including my own answer, because the solution I implemented was different than Kdawg's answer, and I feel it will add value for other people.
First off, I'm new to Jenkins. So if I misspeak, please feel free to correct me. Second, I had a slight learning curve in that there is a difference between a Jenkins "queue item" and a Jenkins "build job". The instant that a "queue item" has been created, there is no "build job" ID, because no build job has started. Also, once a build job has started, the queue item has 5 minutes before it is deleted.
When I perform these tasks:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Jenkins will schedule 3 build jobs to be run in a queue. These will be "queue items". These "queue items" will have a "Queue ID". In the example given in my original question, lets suppose that these three curl commands create "queue items" with "Queue ID"s 121, 122, & 123.
Why is this important?
Because depending on the load of your Jenkins server, the item that was queued may or may not be run immediately. If it runs immediately, then Kdawg's answer is definitely correct. Running his commands:
curl -X GET http://jenkins_srv:8080/queue/item/121/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/122/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true --user name:pass
This will get queue information about each "queue item", and in what returns, there is definitely a way to obtain a "build job" ID, if the build job has started. If a build job has not yet started, this information will be blank.
Here's the additional part that, I feel, adds value.
Once a build job has started, the information in Kdawg's answer will be populated in the response to the three curl -X GET commands. Also, by default, Jenkins is designed to scavenge (garbage collection, choose your own term) the "queue item"s every 5 minutes. So in other words, if all you have is a "queue item" ID and the 5 minute data retention window passes, then you need another mechanism in order to get a "build job" ID from a "queue item" ID.
So, in my case, I'm using Jenkins as a front end, and Ansible on the back end to perform server configuration and application deployments. Some of these application deployments can take 30 minutes or more, well beyond the 5 minute data retention period of the "queue items".
So the problem that I had to solve, if all I have is a "queue item" ID, then how do I find a "build job" ID, regardless of when I'm checking, seconds later or hours later?
Here was my solution (Note that I required XML output, FYI).
I ran this command:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
This command would return this information:
Runtime responseHeaders Date: Day, ## Non Year xx:yy:zz GMT
X-Content-Type-Options: nosniff
Location: http://jenkins_srv:port/queue/item/123/
Content-Length: 0
Server: Jetty(9.4.z-SNAPSHOT)
From here, I can parse out 123 from the Location field.
I then slept for 10 seconds. After the sleep, I run this command on a 10 second loop:
curl -X GET http://jenkins_srv:8080/queue/item/123/api/xml
I did that until I either:
I got a queue item return that included the xpath //executable/number that's shown in Kdawg's example, or
I got HTML 404 status code for more than 10 minutes, meaning the job hasn't been queue'd yet or I passed the 5 minute data retention window.
The loop in this way handles a burdened Jenkins server that's sluggish on handling queue requests. So presumably if I get to the end of 10 minutes, then my approach will still handle the use case that my automation approach has successfully queue'd and run the job, but it's checking Jenkins outside the data retention window. In this case, I would run this command:
curl -X GET http://jenkins_srv:port/job/MY_JOB/api/xml?tree=builds[id,number,result,queueId]&xpath=//build[queueId=123]
This returns the XML info for any "build job" that also contains a queueId of 123, as shown below:
<?xml version="1.0"?>
<build _class="hudson.model.FreeStyleBuild">
<id>456</id>
<number>456</number>
<queueId>123</queueId>
<result>SUCCESS</result>
</build>
In this way, I was able to authoritatively get a "build job" ID while only having a "queue item" ID regardless of the time difference between when I started and when I checked back.
Assuming that you have a location of http://jenkins_srv:8080/queue/item/123/, you can GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true to return information about that queue item (you can also not include ?pretty=true if you don't care about formatting, or use api/xml if you want the results in XML).
I don't know if there's standard documentation on the queue API, but it appears that if the queue item has completed (maybe also if it's currently being built?) it will have an executable node. One for my server looked like this:
"executable" : {
"_class" : "org.jenkinsci.plugins.workflow.job.WorkflowRun",
"number" : 10,
"url" : "http://192.168.99.100:32769/job/configure/10/"
}
You can then GET the API for the URL specified in executable.url. In my case, GET http://192.168.99.100:32769/job/configure/10/api/json?pretty=true. From there, you should have all the information you need, including whether or not the build is currently being built, how long the build took/has taken, the result, etc.
Also, if you want information on your entire build queue, you can GET http://jenkins_srv:8080/queue/api/json?pretty=true
Astonishing that Jenkins doesn't track a request to its conclusion with a unique ID.
One element that persists between the queued item and the build item is the list of parameters. If you have the ability/authority to change the config of the jobs, then add an optional parameter REQUEST_ID that the client plucks from the air (e.g. a UUID) and passes in over REST. Then you can quiz the queue and look for the one with your REQUEST_ID, and you can quiz the list of builds and look for the one with your REQUEST_ID.
There's an interesting thing about this that if you want to queue multiple builds in the loop, you might end up getting SAME QUEUE_ID, This happens especially when you have the same parameter and queued builds have not started up. Basically, Jenkins assumes that you are just trying to build this and instead of multiple builds it just assumes that it needs to spin up only a single build, hence the SAME QUEUE_ID, To overcome this, if you add an extra parameter while building the job like UQ_ID=CURRENT_TIMESTAMP (This param doesn't need to be in build) then you will get the unique build number
If there's no param at all in the build you should define at least one param, Because parameterless build won't allow ANY parameter to be passed in the api
you can fetch job details by id
http://localhost:8080/job/{jobName}/{jobId}/api/json
curl --location --request GET 'http://localhost:8080/job/testPipeline/2/api/json' \
--header 'Authorization: Basic 1234' \
I have a Zabbix server 2.2 and a few linux hosts with websites. How can I get a notification from Zabbix, if the HTTP(s) response code is not 200?
I've tried those triggers without any success:
{owncloud:web.test.rspcode[Availability of owncloud,owncloud availability].last(,10)}#200
{owncloud:web.test.error[Availability of owncloud].count(10,200)}<1
{owncloud:web.test.error[Availability of owncloud].last(#1,10)}=200
But nothing works. I never got an notification, that the code is not 200 anymore even it was 404, because I have renamed the index.php of owncloud to index2.php
I configured the Application and the we the Web Scenario as followed:
if you have already configured the host go to step 1
1) Select the host by Configuration-> Host groups -> select host (example server 1)
2) Go to Config > Hosts > [Host Created Above] > Applications and click on Create Application
3) Now you have to create the Web scenario with the status code check, in my case I checked status code 200. So go to Configuration > Hosts > [Host Created Above] > Web Scenarios and click on Create Web Scenario .
Remark: you have to select the previous application created at the step 2
4) After that without click on Add button go to Steps window and you have to configure the host and parameters for the chek. After that click on Add. In my cas e check the status code 200 response for the HTTP request.
I found the issue. You need to specify the URL to check with file. For example like this in your web scenario:
https://owncloud.example.com/index.php
"Note that Zabbix frontend uses JavaScript redirect when logging in, thus first we must log in, and only in further steps we may check for logged-in features. Additionally, the login step must use full URL to index.php file." - https://www.zabbix.com/documentation/2.4/manual/web_monitoring/example
I also used following expression as trigger:
{owncloud:web.test.fail[Availability of owncloud].last()}>0
you have set a triggers bye Expression
{host name:web.test.rspcode[Scenario name,Steps name].last()}=200
The question has been answered adequately, but I will provide a very much more advanced solution that you could use for all HTTP status codes.
I've created an item that monitors all HTTP status codes of a proxy, graphs them, and then set up multiple different types of triggers to watch last value and counts in last N minutes.
The regex I used to extract all the values from a Nginx or Apache access log is
^(\S+) (\S+) (\S+) \[([\w:\/]+\s[+\-]\d{4})\] \"(\S+)\s?(\S+)?\s?(\S+)?\" (\d{3}|-) (\d+|-)\s?\"?([^\"]*)\"?\s?\"?([^\"]*)\"?\s
I then set many triggers relevant for my particular situation
101 Switching Protocols
301 Moved Permanently
302 Redirect
304 not modified
400 Bad Request
401 Unauthorised
403 Forbidden
404 Not found
500 Server Error
It's also important that your Zabbix agent has permissions to read the log file on the host. You can add the zabbix-agent to the www-data group using this command.
$ sudo usermod -a -G www-data Zabbix
See the tutorial for all the steps in greater detail.