We’re moving our build system from TeamCity to Azure DevOps. We’ve successfully configured the build and had it create a release/deploy within Octopus. We are also able to push Build Information. The problem comes when trying to enable the AzDO Issue Tracker in Octopus. When it’s disabled, we’re able to create releases as expected & the build info page displays commits. When we enable it, we get:
Error while fetching work item references from Azure DevOps: The server returned a sign-in page. Please confirm the Personal Access Token is configured correctly in Azure DevOps Issue Tracker settings, and is authorized to read scopes 'Build' and 'Work items'.
When it’s disabled and I run the connection test, I get (weird that it talks about Jira but whatev):
When I enable it, I get:
The PAT has full access (for now, for testing):
Here’s the full configuration showing we’re using the dev.azure.com URL:
Thanks for reaching out on our community forum. I’m sorry that you’ve been having problems with the ADO tracker.
Would you be able to send me a screenshot of the configuration you have in ADO for the Octopus connection? Also, this is likely not the cause, but to be extra safe, would you try the connection with your ADO Base URL set as https://dev.azure.com/centerx/ instead of https://dev.azure.com/centerx?
Octopus connection screenshot below. I think this is what you’re asking for? As noted, we’re able to push build info & create releases just fine until we enable the issue tracker. At that point, only pushing build info works. The create release fails with the same error we see on the build info page. I’ve included a snippet of the build log below also.
Channel: 'Dev' (this is the default channel)
# Name Version Source Version rules
--- ------------ --------------- ---------------- -----------------------
1 Deploy Dev 2022.01.1-dev User specified Range: PASS Tag: PASS
Creating release...
There was a problem with your request.
- Azure DevOps: Error while fetching work item references from Azure DevOps: The server returned a sign-in page. Please confirm the Personal Access Token is configured correctly in Azure DevOps Issue Tracker settings, and is authorized to read scopes 'Build' and 'Work items'.
Error from Octopus Server (HTTP 400 BadRequest)
Exit code: -7
##[error]Error: The process 'C:\hostedtoolcache\windows\octo\7.4.3576\x64\octo.cmd' failed with exit code 4294967289
##[error]Failed to deploy release The process 'C:\hostedtoolcache\windows\octo\7.4.3576\x64\octo.cmd' failed with exit code 4294967289
Finishing: OctopusCreateRelease
Thanks for that info. Would you be able to send over the complete build log for a successful and failing build/release from ADO? I’m not sure why you’d be successful without the tracker enabled but fail when it’s enabled.
Also, for clarification, are you using the ADO for issue tracking and code repo or do you use other tools like GitHub/Jira? Is your goal to include work items?
Thanks for the clarification on your setup. For the success/failing build logs, you can DM me the logs, upload with a secure upload link (authorized for your email only), or send the logs to support@octopus.com, and we can continue the thread there. I’m okay with whatever you prefer.
I think I figured out one problem. There was a leading zero in our versioning scheme (i.e., 2022.01.x instead of 2022.1.x). AzDO “helpfully” removed the leading 0 from the nuget package version in the feed so I think that’s why Octopus couldn’t find it.
I ran some new builds but now am getting the “looping logins” error (Error while fetching work item references from Azure DevOps: 500 (InternalServerError). “Unable to complete authentication for user due to looping logins”) that was reported in one of the tickets I linked to before from the Build Info screen in Octopus.
With the issue tracker enabled, I still get failures in the build to create a release.
Forgot to mention before, we’re using the Azure package feed for the nuget packages we build, not the Octopus internal registry.
I’ve uploaded two build logs. 551 was successful with the issue tracker off. 552 failed & the only diff was enabling the issue tracker.
Something came to mind when reviewing our ADO tracker documentation. Were you pushing build info via the create Octopus release step in your Azure pipeline? If so, you’d want to disable that as it can cause conflicts with the Tracker. Our docs page has more info - Azure DevOps work item tracking integration - Octopus Deploy.
Ok, so at least that possibility is out. A colleague noticed that the build logs you sent were performed on different machines. Do you think that could be contributing to the errors? Can you force build on one machine so we can test if this is related to the build machine?
I doubt it. We’re using the Microsoft hosted agents so there’s not much control on the individual machine. It’s been repeatable across multiple runs tho
Can you recreate the personal access token inside Azure and try using a completely new token? I know that you had sent a screenshot showing full access, but with the initial access token error and the looping login, it seems token or access permission related.
I did that yesterday when I went & validated the token worked via Postman just to be sure.
Is there a way for me to validate the version of the extension installed? I noticed a comment in the github repo about supporting spaces in project names from November but the DLL on our server is from April. We have a space in our project name, so that could impact us. Can extensions be updated independently of the main software?
You should be able to see what version of the plugin you’re using on your plugin management page in ADO. The plugin is updated and versioned separately from Octopus. You could also try uninstalling the plugin and reinstalling/reconfiguring since we aren’t making any progress with troubleshooting.
Ah I see. That is included in Octopus as a whole but it’s not really a separate thing like ‘tracker’ makes it sound. The extension in ADO is really the ‘tracker’, it just communicates with Octopus server and allows for ADO to push related build info to Octopus.
I’ll have to reach out to the development team to get some clarity on that but I will get back to you as soon as I hear from them. I’ll also ask if they have any advice on your errors, maybe we can get pointed in the right direction.
Just stepping in for Brent from the Australia based team!
After some discussion with the engineers, we have decided to release a build which should contain a fix for this issue early directly to you, so that you can get unblocked.
The build is 2021.3.10526 and is currently making it’s way through our testing before it becomes available in GA. It’s looking very promising but as it’s currently making it’s way through our testing suites, there could be some undiscovered issues and so additional caution is advised.
Before upgrading, please make sure to take a full backup of the Database and Master-key
It includes a number of improvements regarding performance and diagnostics and should allow us to better see what’s going on if the issue isn’t directly resolved.
Please feel free to let me know if you have any questions or concerns!
