huserben / TfsExtensions

Extensions for TFS 2015+ such as custom Widgets (require TFS 2017) and Build Tasks
MIT License
45 stars 22 forks source link

Use Release Environment Variables when Task is used in Context of Release #106

Closed rfennell closed 5 years ago

rfennell commented 5 years ago

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

2018-09-21T12:25:35.8601958Z Trying to fetch authentication token from system...
2018-09-21T12:25:35.8601958Z Using OAuth Access Token
2018-09-21T12:25:35.8601958Z Build shall be triggered for same user that triggered current build: Richard Fennell (Work ID)

These same release stages are failing with the error

2019-01-29T12:36:03.9918075Z Using OAuth Access Token
2019-01-29T12:36:03.9918075Z Build shall be triggered for same user that triggered current build: Microsoft.VisualStudio.Services.TFS
2019-01-29T12:36:03.9918075Z Build Queue was specified as string: Hosted VS2017 - trying to fetch Queue ID for the queue...

So the user has changed, any idea how I grant trigger build rights to this user?

huserben commented 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?

rfennell commented 5 years ago

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.

huserben commented 5 years ago

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.

rfennell commented 5 years ago

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

huserben commented 5 years ago

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.

rfennell commented 5 years ago

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.

huserben commented 5 years ago

I was thinking about something along those lines, thanks for the input, I will try it then like this

huserben commented 5 years ago

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:

grafik grafik

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.

huserben commented 5 years ago

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.

rfennell commented 5 years ago

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?

huserben commented 5 years ago

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: grafik

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

rfennell commented 5 years ago

My mistake, lets try again

rfennell commented 5 years ago

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

huserben commented 5 years ago

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.