I am using a curl PUT command to update the pull-request description. It is updating the description but removing the existing (already added) reviewers.
The curl command I am using to update the pull-request description:
curl -s -X PUT -u '<username>':'<password>' -H "Content-Type: application/json" -v -d '{"version": 1, "description": "'"should go together"'"}' https://{bitbucket.com}/rest/api/1.0/projects/{project_key}/repos/{repo_slug}/pull-requests/{pull_request_id}
Unfortunately you need also to pass the reviewers in the curl command:
curl -s --user USER:PASS --data #- --header 'Content-Type:application/json' --request PUT BITBUCKET-SERVER/rest/api/1.0/projects/PROJECT/repos/REPO/pull-requests/PULL-REQUEST <<EOF
{
"version": VERSION,
"description": "DESCRIPTION",
"reviewers": [
{
"user": {
"name": "REVIEWER-1"
},
"user": {
"name": "REVIEWER-2"
}
}
]
}
EOF
The Bitbucket API documentation says:
Note: the reviewers list may be updated using this resource. However
the author and participants list may not.
Related
First of all, please take note of the new API changes:
https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param/
The problem seems to be that I have to exchange a github personal access token for a temporary token, in order to read from raw.githubusercontent.com.
I have this request info:
set -e
export github_personal_access_token=a8f464fdxxxxxxxxxxxxxxxxxxxxxxfb89e6be
export file_url="https://api.github.com/repos/oresoftware/live-mutex/contents/package.json?ref=master"
mkdir tmp && cd tmp
curl -H "Authorization: token $github_personal_access_token" "$file_url" 2> err.log > output.json
the output.json looks like:
{
"name": "package.json",
"path": "package.json",
"sha": "6a2d55983bb641ff217d822d8e60dbb6c8f85ea3",
"size": 1343,
"url": "https://api.github.com/repos/ORESoftware/live-mutex/contents/package.json?ref=master",
"html_url": "https://github.com/ORESoftware/live-mutex/blob/master/package.json",
"git_url": "https://api.github.com/repos/ORESoftware/live-mutex/git/blobs/6a2d55983bb641ff217d822d8e60dbb6c8f85ea3",
"download_url": "https://raw.githubusercontent.com/ORESoftware/live-mutex/master/package.json",
"type": "file",
"content": "ewogICJuYW1lIjogImxpdmUtbXV0ZXgiLAogICJ2ZXJzaW9uIjogIjAuMi4y\nNCIsCiAgImRlc2NyaXB0aW9uIjogIlNpbXBsZSBtdXRleCB0aGF0IHVzZXMg\nYSBUQ1Agc2VydmVyOyB1c2VmdWwgaWYgeW91IGNhbm5vdCBpbnN0YWxsIFJl\nZGlzLCBldGMuIiwKICAibWFpbiI6ICJkaXN0L21haW4uanMiLAogICJ0eXBp\nbmdzIjogImRpc3QvbWFpbi5kLnRzIiwKICAidHlwZXMiOiAiZGlzdC9tYWlu\nLmQudHMiLAogICJiaW4iOiB7CiAgICAibG14X2FjcXVpcmVfbG9jayI6ICJh\nc3NldHMvY2xpL2FjcXVpcmUuanMiLAogICAgImxteF9yZWxlYXNlX2xvY2si\nOiAiYXNzZXRzL2NsaS9yZWxlYXNlLmpzIiwKICAgICJsbXhfaW5zcGVjdF9i\ncm9rZXIiOiAiYXNzZXRzL2NsaS9pbnNwZWN0LmpzIiwKICAgICJsbXhfbGF1\nbmNoX2Jyb2tlciI6ICJhc3NldHMvY2xpL3N0YXJ0LXNlcnZlci5qcyIsCiAg\nICAibG14X3N0YXJ0X3NlcnZlciI6ICJhc3NldHMvY2xpL3N0YXJ0LXNlcnZl\nci5qcyIsCiAgICAibG14X2xzIjogImFzc2V0cy9jbGkvbHMuanMiLAogICAg\nImxteCI6ICJhc3NldHMvbG14LnNoIgogIH0sCiAgInNjcmlwdHMiOiB7CiAg\nICAidGVzdCI6ICIuL3NjcmlwdHMvdGVzdC5zaCIsCiAgICAicG9zdGluc3Rh\nbGwiOiAiLi9hc3NldHMvcG9zdGluc3RhbGwuc2giCiAgfSwKICAicjJnIjog\newogICAgInRlc3QiOiAiLi90ZXN0L3NldHVwLXRlc3Quc2ggJiYgc3VtYW4g\nLS1kZWZhdWx0IgogIH0sCiAgInJlcG9zaXRvcnkiOiB7CiAgICAidHlwZSI6\nICJnaXQiLAogICAgInVybCI6ICJnaXQraHR0cHM6Ly9naXRodWIuY29tL09S\nRVNvZnR3YXJlL2xpdmUtbXV0ZXguZ2l0IgogIH0sCiAgImF1dGhvciI6ICJP\nbGVnemFuZHIgVkQiLAogICJsaWNlbnNlIjogIk1JVCIsCiAgImJ1Z3MiOiB7\nCiAgICAidXJsIjogImh0dHBzOi8vZ2l0aHViLmNvbS9PUkVTb2Z0d2FyZS9s\naXZlLW11dGV4L2lzc3VlcyIKICB9LAogICJob21lcGFnZSI6ICJodHRwczov\nL2dpdGh1Yi5jb20vT1JFU29mdHdhcmUvbGl2ZS1tdXRleCNyZWFkbWUiLAog\nICJkZXBlbmRlbmNpZXMiOiB7CiAgICAiQG9yZXNvZnR3YXJlL2pzb24tc3Ry\nZWFtLXBhcnNlciI6ICIwLjAuMTI0IiwKICAgICJAb3Jlc29mdHdhcmUvbGlu\na2VkLXF1ZXVlIjogIjAuMS4xMDYiLAogICAgImNoYWxrIjogIl4yLjQuMiIs\nCiAgICAidGNwLXBpbmciOiAiXjAuMS4xIiwKICAgICJ1dWlkIjogIl4zLjMu\nMiIKICB9LAogICJkZXZEZXBlbmRlbmNpZXMiOiB7CiAgICAiQHR5cGVzL25v\nZGUiOiAiXjEwLjEuMiIsCiAgICAiQHR5cGVzL3RjcC1waW5nIjogIl4wLjEu\nMCIsCiAgICAiQHR5cGVzL3V1aWQiOiAiXjMuNC4zIgogIH0KfQo=\n",
"encoding": "base64",
"_links": {
"self": "https://api.github.com/repos/ORESoftware/live-mutex/contents/package.json?ref=master",
"git": "https://api.github.com/repos/ORESoftware/live-mutex/git/blobs/6a2d55983bb641ff217d822d8e60dbb6c8f85ea3",
"html": "https://github.com/ORESoftware/live-mutex/blob/master/package.json"
}
}
but I just want the raw file content, not the metadata. The metadata does give me a link to the raw content:
https://raw.githubusercontent.com/ORESoftware/live-mutex/master/package.json
but for private repos, it requires an access token. So is there an easier way to do this other than this?
curl -H "Authorization: token $github_personal_access_token" "$file_url" |
jq -r '.content' | base64 -d > output.json
like I said, the biggest problem is I don't have a valid access_token in hand, and I can get an access token to download the file from the download_url, but that requires extra scripting steps. Looking for a single command. AKA, I don't want to have to install jq in a docker image if possible.
GitHub supports different media types to indicate what the client wishes to accept. In your case, you can get the raw file like this:
curl -H "Accept: application/vnd.github.v3.raw" \
-H "Authorization: token $github_personal_access_token" \
"$file_url" 2> err.log > output.json
We are researching about the Orion Context Broker technology using local Docker containers and trying to integrate the local Context Broker with an external Context Provider.
Specifically, we are trying to retrieve data from this Context provider:
https://streams.lab.fiware.org/v2/entities?type=AirQualityObserved&options=keyValues
Using the headers:
fiware-service: environment
fiware-servicePath: /Madrid
Concretely, our objective is to achieve a registration from our Context Broker to this node of the provider, in order to get some attributes that we don't have in local (in that example, the attribute is called "NO").
The request we are sending for the registration is the following one:
curl -iX POST \
'http://localhost:1026/v2/registrations' \
-H 'Content-Type: application/json' \
-d '{
"description": "Air Quality Madrid",
"dataProvided": {
"entities": [
{
"id": "Madrid-AirQualityObserved-28079059-latest",
"type": "AirQualityObserved"
}
],
"attrs": [
"NO"
]
},
"provider": {
"http": {
"url": "https://streams.lab.fiware.org"
}
}
}'
Additionally, we have created a local entity with the same id as in the request: Madrid-AirQualityObserved-28079059-latest
After that information, the question is:
Is it possible to include the specific fiware-service and fiware-servicePath headers into the registration request? What is the way to include them?
Thanks in advance.
EDIT:
I've been doing more tests with the following commands:
For registering to the context provider, using the specific headers for the desired service. For now, the local entity is not created in the local context broker.
curl -iX POST \
'http://localhost:1026/v2/registrations' \
-H 'Content-Type: application/json' \
-H 'fiware-service: environment' \
-H 'fiware-servicepath: /Madrid' \
-d '{
"description": "Air Quality Madrid",
"dataProvided": {
"entities": [
{
"id": "Madrid-AirQualityObserved-28079059-latest",
"type": "AirQualityObserved"
}
],
"attrs": [
"NO"
]
},
"provider": {
"http": {
"url": "https://streams.lab.fiware.org"
}
}
}'
Then, I've check if the registration has been correctly registered:
curl -X GET http://localhost:1026/v2/registrations \
-H 'fiware-service: environment'
-H 'fiware-servicepath: /Madrid'
Finally, I've tried to retrieve the entity from the provider:
curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest \
-H 'fiware-service: environment' \
-H 'fiware-servicepath: /Madrid'
But the response indicates that there is not any entity for that request. Because of that, I've created the entity in the local context broker, excluding the field that I'm trying to obtain from the provider "NO".
curl -iX POST \
'http://localhost:1026/v2/entities' \
-H 'Content-Type: application/json' \
-H 'fiware-service: environment' \
-H 'fiware-servicepath: /Madrid' \
-d '
{
"id": "Madrid-AirQualityObserved-28079059-latest",
"type": "AirQualityObserved"
}'
However, if I consult the entity with the ID Madrid-AirQualityObserved-28079059-latest, I'm receiving the local data, and the field "NO" is not being retrieved from the provider. That is the response (missing the NO field):
{
"id": "Madrid-AirQualityObserved-28079059-latest",
"type": "AirQualityObserved"
}
What I am doing wrong?
Yes, it's possible.
They are included as regular headers. For instance, if you are using curl, it would be something like -H 'fiware-service: environment' -H 'fiware-servicepath: /Madrid'.
EDIT:
Looking to the query request you are using:
curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest \
-H 'fiware-service: environment' \
-H 'fiware-servicepath: /Madrid'
I see are not incluing the entity type in the query, contrary to the recomendation in the context providers and request forwarding documentantation:
On forwarding, any type of entity in the NGSIv2 update/query matches registrations without entity type. However, the opposite doesn't work, so if you have registrations with types, then you must use ?type in NGSIv2 update/query in order to obtain a match. Otherwise you may encounter problems, like the one described in this post at StackOverflow.
So maybe you should use:
curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest?type=AirQualityObserved \
-H 'fiware-service: environment' \
-H 'fiware-servicepath: /Madrid'
I found this to create credentials in Jenkins using a REST API call, how to update the credentials with a given id using the REST API calls?
curl -X POST 'http://jenkins:8080/credentials/store/system/domain/_/createCredentials' --data-urlencode 'json={
"": "0",
"credentials": {
"scope": "GLOBAL",
"id": "apicredentials",
"username": "apicredentials",
"password": "P#$$W0rd",
"description": "apicredentials",
"stapler-class": "com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl"
}
}'
Example with xml file:
$ cat credential.xml
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<scope>GLOBAL</scope>
<id>apicredentials</id>
<username>manu</username>
<password>bar1</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
$ curl -X POST -H content-type:application/xml -d #credential.xml 'http://USER:KEY#JENKINS_URL:8080/credentials/store/system/domain/_/credential/apicredentials/config.xml'
The GitHub API provides a lot of functionality, but is there a way to retrieve the build status for a commit? The GitHub UI provides information from the CI system we have configured, but I can't see this information exposed through the API?
You can access the status for a particular ref
GET https://api.github.com/repos/:owner/:repo/commits/:ref/statuses
For the value of :ref, you can use a SHA, a branch name, or a tag name.
It doesn't provide status directly, but offers you to create a status
That means the CI can have a final build step which publishes the status to GitHub repo that way.
POST /repos/:owner/:repo/statuses/:sha
For example:
{
"state": "success",
"target_url": "https://example.com/build/status",
"description": "The build succeeded!",
"context": "continuous-integration/jenkins"
}
(and that, for a given SHA1)
See for instance "Github Commit Status API with Bamboo from Atlassian", where:
${bamboo.buildResultsUrl} is the GitHub commit SHA1:
<xxx> is a placeholder value, which can be replaced by a value, or a variable ${var} as shown here.
Add those to your plan as Script.
complete.sh:
# specs and cukes results are stored in JUnit format under test-reports
if (grep 'failures="[^0]"' test-reports/* || \
grep 'errors="[^0]"' test-reports/*); then
curl -H "Authorization: token <MY_TOKEN>" --request POST \
--data '{"state": "failure", "description": "Failed!", \
"target_url": "${bamboo.buildResultsUrl}"}' \
https://api.github.com/repos/<USER>/<REPO>/statuses/${bamboo.repository.revision.number} > /dev/null
else
curl -H "Authorization: token <MY_TOKEN>" --request POST \
--data '{"state": "success", "description": "Success!", \
"target_url": "${bamboo.buildResultsUrl}"}' \
https://api.github.com/repos/<USER>/<REPO>/statuses \
/${bamboo.repository.revision.number} > /dev/null
fi
pending.sh:
curl -H "Authorization: token <MY_TOKEN>" --request POST \
--data '{"state": "pending", "description": "Build is running", \
"target_url": "${bamboo.buildResultsUrl}"}' \
https://api.github.com/repos/<USER>/<REPO>/statuses/${bamboo.repository.revision.number} > /dev/null
I am attempting to create a hook using the create hook api found on
http://developer.github.com/v3/repos/hooks/#create-a-hook
but I am getting a 301 when I attempt to post, so I am sure I am doing it wrong...
A couple of questions...
1) How does github know that I can create a hook for that repo if it is private? I am sure I need to authenticate with the POST, but how?
2) Is the following curl statement a valid example of how to create a hook?
curl -v -H "Content-Type: application/json" -X POST -d "{ "name": "cia",
"active": true, "events": [ "push" ], "config": {
"url": "http://requestb.in/######", "content_type": "json" } }"
http://github.com/repos/#####/#####/hooks
I have replaced certain elements with ##### for security sake...
3) If the above is incorrect, may I please have a snippet of a valid example to create a hook for the webhook named "cia"?
curl -usigmavirus24 -v -H "Content-Type: application/json" -X POST -d '{"name": "cia", "active": true, "events": ["push"], "config": {"url": "...", "content_type": "json"}}' https://api.github.com/repos/sigmavirus24/reponame/hooks
Is the correct curl command. The URL you're posting to has to be https://api.github.com/:endpoint where :endpoint in this case is repos/username/reponame/hooks. You also need to use 's around the JSON body for the curl command because otherwise you'll get strings like "{ " concatenated with the output of commands like name, cia, active, events, etc.
Also the -u :username option is necessary for curl so it will tell curl that it MUST authenticate and ask you for the password to do so.
If you don't mind your password being in your bash history (WHICH YOU SHOULD) you can also do -u username:password. Or even better you can base64 encode your credentials in the form username:password and then send that as a header like so: Authentication: Basic <base64-encoded-credentials.