MicrosoftPremier / VstsExtensions

Documentation and issue tracking for Microsoft Premier Services Visual Studio Team Services Extensions
MIT License
56 stars 14 forks source link

Access issue for CreateWorkItem builds from fork #95

Closed Andrii-Papezhuk closed 4 years ago

Andrii-Papezhuk commented 4 years ago

I'm trying to create a new work item for a failed build from the fork and it fails with the error below:

##[error]TF400813: The user '' is not authorized to access this resource.

The same build with the same configuration and PAT token was working fine several weeks ago. Please find task configuration below:

  - task: CreateWorkItem@1
    displayName: 'Create Task If Build Fails'
    condition: failed()
    inputs:
      teamProject: 'XXXXXXXXXXX'
      workItemType: 'Task'
      title: 'Platform Build Failure New Stack'
      assignedTo: 'XXXXXX YYYYYYY <xxxxxxx.yyyyyyy@zzzzz.com>'
      areaPath: 'XXXXXXXXXXX\DevOps'
      iterationPath: 'XXXXXXXXXXX'
      fieldMappings: |
        Description=This item was automatically created by Azure Pipeline. Failed build is linked to this task.
      associate: true
      linkWorkItems: true
      linkType: 'System.LinkTypes.Hierarchy-Reverse'
      linkTarget: 'id'
      targetId: '142432'
      authToken: 'test_token.txt'

No changes in project configuration were executed, I am able to reproduce this issue by specifying an authToken parameter. From my side, it looks like some security rules were updated from extension or Azure DevOps side, and an extension cannot assume user token. Could you please help me in investigation and check from the extension side if everything works fine?

ReneSchumacher commented 4 years ago

Hey,

thanks for reporting this. I'll check my test environment and see if I can reproduce the issue.

ReneSchumacher commented 4 years ago

Hi again,

I cannot reproduce the issue in my environment. Here are a couple things you should check:

  1. Make sure that the PAT hasn't expired or been revoked by someone. The task cannot automatically extend/refresh the PAT.
  2. Is the PAT directly injected in the YAML file? If so, make sure no one changed the value.
  3. Is the PAT stored in a secret variable? If so, please check if the settings to protect secrets for forked repos is configured correctly. See https://docs.microsoft.com/en-us/azure/devops/pipelines/security/repos?view=azure-devops#dont-provide-secrets-to-fork-builds for more information. You need to check the option Make secrets available to builds of forks for the task to work.
Andrii-Papezhuk commented 4 years ago

Hi Thanks for a quick reply

PAT is not expired, checked. I've also checked a configuration for a project, everything looks fine. Secrets are available for a fork. PAT is used as a secret file in my pipeline. I've tried to inject PAT directly in the YAML file, and everything works fine. I can assume that a pipeline doesn't have access to a secret file; however, it's really weird for me.

ReneSchumacher commented 4 years ago

Hm, that's weird indeed. I would recommend reporting this issue through Azure DevOps' feedback channel. Perhaps there is a temporary issue or something specific to your pipeline or organisation?

Andrii-Papezhuk commented 4 years ago

Thanks, @ReneSchumacher for your help!

I managed to resolve this issue by using a secret variable with PAT instead of a secret file. I'll continue the investigation, but for me, it looks like the issue is on the Azure side or in the project configuration.

Thanks & Regards, Andriy