I cannot seem to find the job name of an item in the queue through the API. Am I missing something (obvious)?
I created two dummy jobs that require a machine named "build1" that is offline.
When I access http://JENKINS_URL:8080/queue/api/json I get this:
{
"_class": "hudson.model.Queue",
"discoverableItems": [],
"items": [
{
"_class": "hudson.model.Queue$BuildableItem",
"actions": [
{}
],
"blocked": false,
"buildable": true,
"id": 262,
"inQueueSince": 1529331225093,
"params": "",
"stuck": true,
"task": {
"_class": "org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask"
},
"url": "queue/item/262/",
"why": "build1 is offline",
"buildableStartMilliseconds": 1529331225094,
"pending": false
},
{
"_class": "hudson.model.Queue$BuildableItem",
"actions": [
{}
],
"blocked": false,
"buildable": true,
"id": 260,
"inQueueSince": 1529331219128,
"params": "",
"stuck": true,
"task": {
"_class": "org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask"
},
"url": "queue/item/260/",
"why": "build1 is offline",
"buildableStartMilliseconds": 1529331219128,
"pending": false
}
]
}
And if I access http://JENKINS_URL:8080/queue/item/262/api/json I get nothing more (just the item itself).
However, if I create an item that is put on hold because crontab-created and there's the previous one still in execution, it's no longer a hudson.model.Queue$BuildableItem but a hudson.model.Queue$BlockedItem and there, the task key has a full object with more details... and the name.
Any idea as to where I can find the job name of any item in the queue (and not a specific queue, btw)?
Thanks!
Related
I'm trying to fetch all users from a specific group via an HTTP connector, a registered app, and Microsoft Graph.
The registered app has Directory.Read.All permissions.
My idea is that I'm calling the nextLink as long as it's there while appending all of the fetched users' userPrincipalName to an array eventually filling the array with all users of the group.
My Logic App looks like this:
Unfortunately, I'm just 1 reputation short of posting images, please forgive. The 3 links should provide an overview of the structure of my app.
First, nextLink is initialized to the first Graph API endpoint. This variable is set to the current nextLink through each iteration of the until loop.
Second, For the purpose of this exercise, I only get the top 5. I know there are only 9 users:
Lastly, I call the union method on the "users" array that I initialized earlier and the "value" array from the HTTP get method, to get one single array consisting of all users:
The issue is that the HTTP action always returns the same top 5 users. I've checked that the nextLink provided in the first HTTP GET call to Graph, is correct by copying it from the Runs history and pasting it into Microsoft Graph Explorer and there the next 4 users are correctly returned.
I also made sure that, for each iteration in the until loop, I call the Graph API with the nextLink from the previous iteration as expected.
The nextLink returned inside of the Logic App is exactly the same when I test it in Graph Explorer, but the same nextLink returns 2 different results when called from Graph Explorer and inside my Logic App.
Why is the result always the same top 5 users and not the next 4 users as expected?
If not sure about the reason why you will get this issue, but based on your requirement, I did a sample below:
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"Initialize_variable": {
"inputs": {
"variables": [
{
"name": "GetGroupUrl",
"type": "string",
"value": "https://graph.microsoft.com/v1.0/groups/<your group id>/members?$select=userPrincipalName&$top=5"
}
]
},
"runAfter": {},
"type": "InitializeVariable"
},
"Initialize_variable_2": {
"inputs": {
"variables": [
{
"name": "users",
"type": "array"
}
]
},
"runAfter": {
"Initialize_variable": [
"Succeeded"
]
},
"type": "InitializeVariable"
},
"Until": {
"actions": {
"Compose": {
"inputs": "#union(variables('users'),body('HTTP')['value'])",
"runAfter": {
"HTTP": [
"Succeeded"
]
},
"type": "Compose"
},
"HTTP": {
"inputs": {
"authentication": {
"audience": "https://graph.microsoft.com",
"clientId": "<app id>",
"secret": "<app secret>",
"tenant": "<your secret>",
"type": "ActiveDirectoryOAuth"
},
"method": "GET",
"uri": "#variables('GetGroupUrl')"
},
"runAfter": {},
"type": "Http"
},
"Set_variable": {
"inputs": {
"name": "GetGroupUrl",
"value": "#{if(equals(body('HTTP')?['#odata.nextLink'], null),null,body('HTTP')['#odata.nextLink'])}"
},
"runAfter": {
"Compose": [
"Succeeded"
]
},
"type": "SetVariable"
}
},
"expression": "#equals(variables('GetGroupUrl'), '')",
"limit": {
"count": 60,
"timeout": "PT1H"
},
"runAfter": {
"Initialize_variable_2": [
"Succeeded"
]
},
"type": "Until"
}
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {
"$connections": {
"defaultValue": {},
"type": "Object"
}
},
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {
"properties": {
"text": {
"type": "string"
}
},
"type": "object"
}
},
"kind": "Http",
"type": "Request"
}
}
},
"parameters": {}
}
You can just replace the params with your own and paste it into your logic app code view and test it .
It works for me, as you can see , each request results are different :
Hope it helps .
This issue solved by OP self, this issue is due to queries in request URL , copy OP's comment as an answer :
After fiddling a bit more around with what each of you providing I
found a solution. It seems that when the query arguments are passed to
the HTTP GET outside of the endpoint itself (meaning in the "queries"
field inside of the block) it seems to keep overriding the nextLink.
When writing the endpoint URL out entirely with the odata parameters,
it works as intended.
I am trying to modify the quick sample provided here.
I tried to add a few custom sensor data type but it is failing. Then I tried a few data types mentioned in the documentation which also failed.
I am getting below error
Creating Sensor: {
"DataType": "Noise",
"DeviceId": "some-device-id",
"HardwareId": "SAMPLE_SENSOR_NOISE"
}
Request: POST
https://******.*******.azuresmartspaces.net/management/api/v1.0/sensors
Response Status: 404, NotFound , {"error":
{"code":"404.600.000.001","message":"There is no SensorDataType of the
given name."}}
Can we add custom sensor datatype?
If no then what are the inbuilt data types? or if yes then what went wrong here?
You need to post the DataType when creating the Sensor object. Use “None” if you want to change it later. Swagger DOCs show the “Model” you can expand and see required fields.
If the DataType is not in the api/v1/system/types you will need to enable it or create a new DataType. Create a new DataType POST to the Types with the required information. The minimum is the TypeName and SpaceID to neat the type under. My typical pattern is to create a root space and append any custom twin objects like types to this space.
I believe these are case sensitive names as well.
https://{servicename}.{region}.azuresmartspaces.net/management/swagger/ui/index#/Types
EDIT:
Check your Ontologies with:
https://{servicename}.{region}.azuresmartspaces.net/management/api/v1.0/ontologies
Select these by ID and POST to set them to true to get all available built-in types:
[
{
"id": 1,
"name": "Required",
"loaded": true
},
{
"id": 2,
"name": "Default",
"loaded": true
},
{
"id": 3,
"name": "BACnet",
"loaded": true
},
{
"id": 4,
"name": "Advanced",
"loaded": true
}
]
Then you can query all the given types:
https://{servicename}.{region}.azuresmartspaces.net/management/api/v1.0/types?includes=Description,FullPath,Ontologies,Space
You should receive something like:
[
{
"id": 1,
"category": "DeviceSubtype",
"name": "None",
"disabled": false,
"logicalOrder": 0,
"fullName": "None",
"spacePaths": [
"/system"
],
"ontologies": [
{
"id": 1,
"name": "Required",
"loaded": true
}
]
},
{
"id": 2,
"category": "DeviceType",
"name": "None",
"disabled": false,
"logicalOrder": 0,
"fullName": "None",
"spacePaths": [
"/system"
],
"ontologies": [
{
"id": 1,
"name": "Required",
"loaded": true
}
]
},
{
"id": 3,
"category": "DeviceBlobSubtype",
"name": "None",
"disabled": false,
"logicalOrder": 0,
"fullName": "None",
"spacePaths": [
"/system"
],
"ontologies": [
{
"id": 1,
"name": "Required",
"loaded": true
}
]
},
...Objects,
]
Anyone know how I can get the separate logs (for each pipeline stage) as the Blue Ocean shows. I need to attach them to Jira but I can not find them.
Any idea?
I'm doing the same thing with the global pipeline library I'm building. This is good for cases where you just want to email the logs of a particular failed stage. Here's how hope it helps. On the sample pipeline below a job named test is executed once (build #1)
pipeline {
agent any
stages{
stage("Compile") {
steps {
script {
echo "Compiling..."
}
}
}
stage("Test") {
steps {
script {
echo "Testing..."
}
}
}
stage("Build") {
steps {
script {
echo "Building..."
}
}
}
}
}
Access the API to see execution details. Notice that each object of this JSON includes the attributes id and result.
http://localhost:8080/blue/rest/organizations/jenkins/pipelines/test/runs/1/nodes/
[
{
*snip*
"actions": [],
"displayDescription": null,
"displayName": "Compile",
"durationInMillis": 341,
"id": "6",
"input": null,
"result": "SUCCESS",
"startTime": "2018-11-24T18:14:16.196+0800",
"state": "FINISHED",
"type": "STAGE",
"causeOfBlockage": null,
"edges": [
{
"_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl",
"id": "15",
"type": "STAGE"
}
],
"firstParent": null,
"restartable": true
},
{
*snip*
"actions": [],
"displayDescription": null,
"displayName": "Test",
"durationInMillis": 246,
"id": "15",
"input": null,
"result": "SUCCESS",
"startTime": "2018-11-24T18:14:16.693+0800",
"state": "FINISHED",
"type": "STAGE",
"causeOfBlockage": null,
"edges": [
{
"_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl",
"id": "24",
"type": "STAGE"
}
],
"firstParent": "6",
"restartable": true
},
{
*snip*
"actions": [],
"displayDescription": null,
"displayName": "Build",
"durationInMillis": 270,
"id": "24",
"input": null,
"result": "SUCCESS",
"startTime": "2018-11-24T18:14:17.188+0800",
"state": "FINISHED",
"type": "STAGE",
"causeOfBlockage": null,
"edges": [],
"firstParent": "15",
"restartable": true
}
]
Use result to check the status of a stage (SUCCESS, FAILED, ABORTED, etc...)
Use id to get into a particular stage, for this example the logs of Test stage which has an id of 15.
http://localhost:8080/blue/rest/organizations/jenkins/pipelines/test/runs/1/nodes/15/log/
Testing...
you can find the rest api document through this url:
https://github.com/jenkinsci/blueocean-plugin/tree/master/blueocean-rest
still need to notice this in their document.
The Blue Ocean REST API is a "private API" designed for the Blue Ocean user interface.
It may change without notice at any time.
I have an internal app that uses a webhook listener and some scripting to manipulate the input data. I'm posting this to it:
curl -X POST -d '{
"assignment_id": 12345,
"updated_custom_fields": [{
"name": "RNVIDAYEBB",
"value": "updated!"
},
{
"name": "QUFTXSIBYA",
"value": "and me too"
}
],
"custom_fields": [{
"id": 981,
"name": "RDEXDPVKRD",
"fields": [
{
"id": 4096,
"name": "RNVIDAYEBB",
"default": "EDJEAJICYW",
"required": true,
"value": "Blah"
},
{
"id": 4097,
"name": "QUFTXSIBYA",
"default": "",
"required": true,
"value": ""
}]
}]
}' "https://hooks.zapier.com/hooks/catch/......"
My script is as follows:
update_custom_fields_by_name_pre_write: function(bundle) {
var updatedFields = _.map(bundle.request.data.custom_fields, function(group) {
return _.map(group.fields, function(field) {
return _.extend(field, _.findWhere(bundle.request.data.updated_custom_fields, { name: field.name} ));
});
});
bundle.request.data = updatedFields;
return bundle.request;
}
I know that the merging logic is good, but it appears that the custom_fields and updated_custom_fields arrays are not present in the bundle.request.data object. Anyone know how to get access to them in the script?
It seems like you should be using update_custom_fields_by_name_catch_hook to capture the incoming static webhook data (instead of _pre_write). If you use that, you can capture the data within bundle.cleaned_request.custom_fields and bundle.cleaned_request.updated_custom_fields.
I've been trying for a few days now to get the Breeze 1.4.9 to work with a rails back end in a different manner than the Breeze Ruby SPA sample. I would rather send bulk save changes instead of trying to send RESTful calls to the server on every entity change. To that end, I've written a rails controller/model methods that will parse out all the different entities in a Breeze SaveChanges POST and act accordingly. Everything works great except that the response to SaveChanges POST doesn't seem to satisfy all the checks for Breeze and EntityManager.hasChanges() is still true even after the response is processed successfully.
Here's a typical cycle:
Breeze requests my hand crafted metadata and parses it fine:
{
"metadataVersion": "1.0.5",
"namingConvention": "rubyNamingConvention",
"localQueryComparisonOptions": "caseInsensitiveSQL",
"dataServices": [
{
"serviceName": "breeze\/Breeze\/",
"hasServerMetadata": true,
"jsonResultsAdapter": "webApi_default",
"useJsonp": false
}
],
"structuralTypes": [
{
"shortName": "VarianceReason",
"namespace": "Icon",
"autoGeneratedKeyType": "Identity",
"defaultResourceName": "VarianceReasons",
"dataProperties": [
{
"name": "id",
"dataType": "Int32",
"isNullable": false,
"defaultValue": 0,
"isPartOfKey": true,
"validators": [
{
"name": "required"
},
{
"name": "int32"
}
]
},
{
"name": "name",
"dataType": "String",
"isNullable": false,
"defaultValue": "",
"maxLength": 256,
"validators": [
{
"name": "required"
},
{
"maxLength": 256,
"name": "maxLength"
}
]
},
{
"name": "createdAt",
"dataType": "DateTime",
"isNullable": false,
"defaultValue": "1900-01-01T08:00:00.000Z",
"validators": [
{
"name": "required"
},
{
"name": "date"
}
]
},
{
"name": "updatedAt",
"dataType": "DateTime",
"isNullable": false,
"defaultValue": "1900-01-01T08:00:00.000Z",
"validators": [
{
"name": "required"
},
{
"name": "date"
}
]
}
]
}
],
"resourceEntityTypeMap": {
"VarianceReasons": "VarianceReason:#Icon"
}
}
I make an entity change in Breeze and it POSTs the below to rails when I call em.SaveChanges():
{
"entities":[
{
"id":-1,
"name":"anyuthingasd",
"created_at":"1900-01-01T08:00:00.000Z",
"updated_at":"1900-01-01T08:00:00.000Z",
"entityAspect":{
"entityTypeName":"VarianceReason:#Icon",
"defaultResourceName":"VarianceReasons",
"entityState":"Added",
"originalValuesMap":{
},
"autoGeneratedKey":{
"propertyName":"id",
"autoGeneratedKeyType":"Identity"
}
}
}
],
"saveOptions":{
}
}
Rails then responds with:
{
"KeyMappings":[
{
"EntityTypeName":"VarianceReason:#Icon",
"TempValue":-1,
"RealValue":16
}
],
"Entities":[
{
"id":16,
"name":"anyuthingasd",
"created_at":"2014-05-02T14:21:24.221Z",
"updated_at":"2014-05-02T14:21:24.221Z",
"Entity":null
}
]
}
Breeze then merges in the new id key mapping but doesn't clear the cache, so next time I make another entity change it still has the first change which has already persisted to the server and the new change. Can anyone tell me what I'm not responding with from the rails side that makes Breeze EntityManager not satisfied? I'm trying to trace through the 15k lines of code but can't say I'm a JS ninja.
We really do need to show folks how to build a data service adapter for whatever service they've got.
In this case, it appears you chose to implement something like the SaveChanges method in C# on the Web API. In other words, you've chosen to emulate the out-of-the-box Breeze protocol. That's cool! And non-trivial too so kudos to you.
I think what's missing from the entity JSON in your save response is the EntityType name. Breeze can't find the corresponding cached entities without knowing their types and thus cannot update their change-states.
Again, because you've decided to use the default Web API data service adapter, you'll want to return a response that adapter expects. That adapter defines a "jsonResultsAdapter" that expects each JSON entity data object to have a $type property specifying the full type name (namespace.typename).
In your example, I think you'd want to return
...
"Entities":[
{
"$type": "Icon.VarianceReason",
"id":16,
"name":"anyuthingasd",
"created_at":"2014-05-02T14:21:24.221Z",
"updated_at":"2014-05-02T14:21:24.221Z",
}
]
How about an example?
I suspect that you may not have easy access to a server with Web API that can show you what a save response looks like with the default adapter. Therefore, I've pasted below a Todo app's saveChanges request and response for a change-set that includes a new, a modified, and a deleted TodoItem.
The Request
Below is the payload of the POST request to the "SaveChanges" endpoint. It is probably way more verbose than you need (more verbose than I'd need). Just to pick one example, the "autoGeneratedKey" is of no interest to the server whatsoever.
I'm just showing you what the default data service adapter sends. Someday you'll write your own to do it the way you want it. For now I suppose there is no harm in sending too much crappola ... as long as you're happy to ignore it on the Rails end :-)
{
"entities": [
{
"Id": 5,
"Description": "Cheese",
"CreatedAt": "2012-08-22T09:05:00.000Z",
"IsDone": true,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Deleted",
"originalValuesMap": {
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
},
{
"Id": 6,
"Description": "Modified Todo",
"CreatedAt": "2012-08-22T09:06:00.000Z",
"IsDone": false,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Modified",
"originalValuesMap": {
"Description": "Wine"
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
},
{
"Id": -1,
"Description": "New Todo",
"CreatedAt": "2014-05-02T17:34:00.904Z",
"IsDone": false,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Added",
"originalValuesMap": {
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
}
],
"saveOptions": {
}
}
The Response
The $id property is a node counter. It's useful when you have repeated entities so you don't have to worry about cycles or repeated entity data in your payload (an object with a $ref property is the placeholder for the repeated entity). You can ignore $id if you don't need this feature (and you rarely would need it in a save result).
Notice that the $type is in the .NET "CSDL" type format "namespace.typename", not the Breeze type format "typename:#namespace". This is an artifact of the data service adapter's jsonResultsAdapter ... which you can change to better suit your Rails implementation. None of this is cast in stone. I'm just reporting what these adapters do as delivered.
You can ignore the assembly name (", Todo-Angular") in the $type value; Breeze doesn't care about it.
Notice that the deleted "Cheese" entity was returned with all of its contents. I bet you don't have to do that. You could get away with returning a stripped down version that simply lets the client know Rails got the message:
{
"$id": "2",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 5
},
And now ... the complete JSON response body:
{
"$id": "1",
"$type": "Breeze.ContextProvider.SaveResult, Breeze.ContextProvider",
"Entities": [
{
"$id": "2",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 5,
"Description": "Cheese",
"CreatedAt": "2012-08-22T09:05:00.000Z",
"IsDone": true,
"IsArchived": false
},
{
"$id": "3",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 6,
"Description": "Modified Todo",
"CreatedAt": "2012-08-22T09:06:00.000Z",
"IsDone": false,
"IsArchived": false
},
{
"$id": "4",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 7,
"Description": "New Todo",
"CreatedAt": "2014-05-02T17:34:00.904Z",
"IsDone": false,
"IsArchived": false
}
],
"KeyMappings": [
{
"$id": "5",
"$type": "Breeze.ContextProvider.KeyMapping, Breeze.ContextProvider",
"EntityTypeName": "Todo.Models.TodoItem",
"TempValue": -1,
"RealValue": 7
}
],
"Errors": null
}