Access Gitlab Api from Youtrack Workflow
Hi, i am trying to trigger events on Gitlab from Youtrack. This will be used for several reasons like:
- Creating branch on new Epic for release
- Running Deployment pipelines for specific states for Release
As first step i created based on Gitlab Api a new branch using Postman easily.
I tried to create a workflow and use the entity.http to set again the rest but i always get 404 error.
To try to make it even more simple i tried just to get the project in Gitlab and at with this get request the response give me back the login page of Gitlab.
For some reason the personal token of Gitlab used in Postman does not work in Youtrack.
From Gitlab's api you can access it with 3 ways using personal/project token
- curl "https://gitlab.example.com/api/v4/projects?private_token=<your_access_token>"
- curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects"
- curl --header "Authorization: Bearer <your_access_token>" "https://gitlab.example.com/api/v4/projects"
In Postman i used the second. In Youtrack i used all and none worked.
I giving all cases in one in order not to write different:
const baseUrl = 'https://gitlab.{my domain}/api/V4';
const projUrl= '/projects';
const token = 'myToken';
const branchUrl = '/projects/34/repository/branches';//34 is the id on my gitlab project that succeed with Postman
const token2 = `Bearer myToken`;//another way found in gitlab-connection workflow that is not really working cause ctxAccess is not completed by anything
const connection = new http.Connection(baseUrl)
.addHeader('Accept', 'application/json, */*')
.addHeader("PRIVATE-TOKEN",token);// in another case i have done the Authorisation with token2
const payload = [];
payload.push({
name: 'branch',
value: ctx.issue.name //trying to get the issue name of it
});
payload.push({
name: 'ref',
value: 'master'
});
payload.push({
name: 'private_token',
value: 'myToken'
});
// const response = connection.postSync(branchUrl,payload, null);// this was try to create branch
const response = connection.getSync(projUrl);// this was try to get the project and it fails also if i add queryParams=payload
Please sign in to leave a comment.
It seems that i found the way to solve it. User has to use the basiAuth function of http and to pass the token from the header. It did not work only with one of the two.
So function to connect is like this
And it is not name but issue.summary
Please let us know if you face any further questions.
Thank you for answer Anastasia i should have been more carefull with issue.summary field. The main question is why Postman does not request basicAuth and works only with personal Token as gitlab api explains and from Youtrack we need to pass also the username and password for the gitlab account. It can be used but is it something wrong or i did not understand something?
One more comment it is somehow problem if i have to place credential of some "admin" user of out gitlab to youtrack where someone other from the company could go and check the workflow and pick the credentials.
Hi!
I'm Sergey from the YouTrack team.
Both private-token and oauth (Bearer) authorization should work perfectly fine. Just in case, I've tested it with my GitLab instance and could authenticate without any issues. So I recommend you perform basic troubleshooting, e.g., add logging for the response to see what GitLab returns. Your postSync would never work in your initial workflow, as you didn't pass the branch name correctly in the payload. getSync should have worked, though, given the request itself was composed with the correct data.
Your private-token header is redundant here, as the auth is done when you call the basicAuth method, so even if you drop this header, it will work.
Currently, there's no dedicated workflow feature to store secrets. We have a related feature request in our public tracker to implement it: https://youtrack.jetbrains.com/issue/JT-59587. Please feel free to vote for this issue. This helps us gauge how much impact this feature will have on our customer base, and you’ll also get subscribed to the issue’s notifications. To do so, sign in to JetBrains YouTrack and hit a thumbs-up icon.
As a workaround, you can create a private issue hidden to a specific set of users (or just yourself) and store secrets in, for example, a description. Then retrieve it via a workflow. In this case, mind that system admins have a override visibility permission by default that allows them to see even hidden issues.
Hi Sergey thank you for the response. Allow me to take thing one by one.
Access:
So in your test basic Auth and token worked separately?
Is it possible that you can share it ? i mean the consept of the function setup like i tried with hidden data so i can reuse and compare to find my mistake. I am missing something and i really can not see it.
Thank you for the idea of a private issue that can be accessed from the workflow so now shown to developers in general. I can use it as last solution but i have to find out why the login with the token does not work.
Post/Get:
Regards
I have to admit that i retried after the confirmation from your side that it should work only with the token. And it did worked successfully. No really big changes just i commented the basicAuth function so i really do not know what was the issue if i had also something else wrong at that time.
There is one thing that is for sure different my first tests where on version 63553 and also yesterday we updated to 64281.
We are also waitng for the next release to fix this git ci/cd issue that we had and Anastasia identified 2 bugs from this that are already fixed. Is it possible that you know when this will come out?
Thanks for your response.
Yes, that's the point of the basic auth. However, according to the GitLab logs, this is not a recommended auth way, so better pass a token as suggested.
There's nothing special about how you should do it. It works with the code you shared as well. The only thing is, as I mentioned before, I don't have any means to verify the data you pass like IDs and tokens.
JavaScript's if statements should help run the code only if you get a specific response.
There were no changes to the http module in this upgrade.
There's no specific ETA. You should follow related issues in our public tracker, as they are updated accordingly when the fixes are released.
Hi thank you for you help. Every thing works with the token normally. I do not know now what was the obstacle before cause i tried but probably it was something that i corrected along with several other changes. Either way it works at it was suppose to do and as you said it does only with token.
I still have to find a proper way to block the workflow to run if some of the rest api that happen do not return proper response (but not by the code cause it could be some empty result but 200) but i made a different post for this, though the agent that answered didn't really checked what was my question so didn't help at all.
Thank you anyway lets close this post.
Regards
Thanks for your response.
As I understand, you're already discussing it with my colleague in some other thread or ticket, but I'll just leave some details here as well in case someone else faces the same question. A response is not only about the code, it contains different properties including headers and body. So you can make any conditional statements depending on these properties.