Closed rfennell closed 5 years ago
Hi @rfennell
Thanks for your feedback.
so just for me to summarize if I got everything right:
As the task wasn't update in a while the only thing that could have happened is that something within Azure might have changed - assuming you're using Azure DevOps.
I just checked how the user name and id's are fetched, and the task is using the build variables Build.RequestedFor and Build.RequestedForId https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azdevops
So we use the same variables when running in a release context. What happens there is that it will take the Primary Build and use those values according to https://docs.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=azdevops&tabs=batch
But as I got your problem description it used to work in any case and now it's broken in any case? So it's not an issue depending on who/how the primary build of the release got triggered.
Could you check the following: If you look at the "Initialize Job" Section of the Release you should see a list of all environment variables. Are "_BUILDREQUESTEDFOR" and _"BUILDREQUESTEDFORID" set to something meaningful?
Hi, yes I too suspect a change in Azure DevOps
In the working instance (21/9/19) [BUILD_REQUESTEDFOR] --> [Richard Fennell (Work ID)] [BUILD_REQUESTEDFORID] --> [98636f62-ee75-4555-88ca-05c113cf6a63]
Failing build [BUILD_REQUESTEDFOR] --> [Microsoft.VisualStudio.Services.TFS] [BUILD_REQUESTEDFORID] --> [00000002-0000-8888-8000-000000000000]
So the user triggering the release (from a build triggered by a GitHub PR) has changed.
I doubt is you your task, just wondered if you had seen this before and new how to grant suitable rights.
I will checking with Microsoft, I have the advantage of being a DevOps MVP so know a few people in the product group, and will will report back.
Hi
ok please let me know if you find something out and as well if something maybe needs to change in the task itself.
You could check in the logs maybe what the other "RequestedFor" parameters are set to. I think there is at least one that is "RELEASE_REQUESTEDFOR", maybe this one is still set to the proper value?
As a workaround you can also "force" that it's triggered for you by using a Personal Access Token that was created for you instead the OAuth authentication. But that's probably just hiding the real issue here, but anyway just to not block you for the moment that should work.
On the failing build trigger in the release the values are
[RELEASE_REQUESTEDFOR] --> [Richard Fennell (Work MSA)] [RELEASE_REQUESTEDFORID] --> [b1fce0e9-fbf4-4202-bc09-a290def3e98b]
So this does appear as expected.
Yes, moving to a PAT as opposed to OAUTH is a good workaround
Ok, interesting.
I can have a look into it, it should be simple to use the dedicated variable depending on the context (Build or Release). Now I just need to figure out how I easily can determine this.
Once I upload a new version with this I'll let you know. It probably takes a few days till I get to it though.
On my extensions I check if I am in a release by looking for the RELEASE_REQUESTEDFOR as this can only be seen in a release. I use this then fall back to the BUILD variables.
I was thinking about something along those lines, thanks for the input, I will try it then like this
Hi @rfennell
I'm currently working on fixing your problem properly. As you suggested I'm using a check whether the RELEASE_REQUESTEDFOR is available to determine the context:
So in any case we will now go for the Release variable when we are in the context of a release, but I don't think that should be a problem - It was rather that it worked "by chance" before in the Release context as I wasn't even considering that case in the beginning.
So if you don't have any objections I will publish the new version in the coming days. I would let you know once they're available so you can give it a try.
Hi @rfennell
I just updated the tasks and the TriggerBuildTask now comes with "Context-Awareness". Please give it a try and let me know whether it works as expected or not.
Just tried again, got Task Version : 2.8.7 is that correct?
Still getting
Trying to fetch authentication token from system...
2019-02-06T17:01:59.5399757Z Using OAuth Access Token
2019-02-06T17:01:59.5399757Z Build shall be triggered for same user that triggered current build: Microsoft.VisualStudio.Services.TFS
Did you need me to change some setting?
Version 2.8.7 is the latest versoin of the Task in version 2, however the latest version would be 3.0.7 by now. If you're using Azure DevOps you have to manually upgrade to the 3.* version:
The "major" update was done as the Interface slightly changed, however in most scenarios there is actually no change needed. It's described in more detail here: https://github.com/huserben/TfsExtensions/blob/master/BuildTasks/overview.md#version-3-now-available
My mistake, lets try again
OK, now I see
2019-02-06T17:29:24.5261870Z Server URL: https://richardfennell.visualstudio.com/
2019-02-06T17:29:24.5261870Z Trying to fetch authentication token from system...
2019-02-06T17:29:24.5261870Z Using OAuth Access Token
2019-02-06T17:29:25.0793282Z Provided team project was guid.
2019-02-06T17:29:25.0793282Z Context is Release - using Release Environment Variables
2019-02-06T17:29:25.0793282Z Build shall be triggered for same user that triggered current Release: Richard Fennell (Work MSA)
And one of my builds works, another fails, but that is a rights issue for that this user, so I think you have a fix.
Thanks
Ok, in that case I'll close this one. Thanks for reporting and please continue to raise issues in case you run into problems or have a feature request.
I have been using the trigger build extensively with release pipelines that are triggered of PR's on code on GitHub.
In the past I have seen the logging
These same release stages are failing with the error
So the user has changed, any idea how I grant trigger build rights to this user?