When I create and push build information to Octopus using the Azure DevOps OctopusMetadata@5 tool, I can see the commit information being included, but not any work items (which presumably refers to Azure DevOps work items, which we’re not using, in favour of Jira). We have the Jira plugin for Octopus installed and configured correctly (the Test functionality confirms that), but even when the commit messages or commit branch names include a Jira ticket number, those details are not ending up in the release notes for the release.
Thank you for contacting Octopus Support and sorry to hear you are having issues with Octopus showing the work items from JIRA Cloud.
Has this started happening recently or has this never worked? If it has just started is there anything you can think of that would have triggered this behaviour to occur? I noticed you said you had version controlled the project (source code in Atlassian BitBucket Cloud), has it started happening since you version-controlled it?
Am I able to create a support user on your instance please just so I can have a look at how you have this configured? Can I also get the name of the project this is happening to.
With this particular configuration, I don’t believe it has ever worked. Previously I was using Atlassian BitBucket Pipelines instead of Azure DevOps, and it didn’t work then; I believe that was because there is explicitly no support in the Pipelines component for submitting work items. I’m not so sure about the Azure DevOps support for it, especially when using Jira to store the work items.
I have had this work before on other projects, using BitBucket/Jira/TeamCity as my toolchain, so it may be an Azure DevOps issue (as a wild guess).
When I mentioned the project was source-controlled, I was referring to the application, not the Octopus configuration; we did start looking at source-controlling the Octopus configuration, but ran across a few blocker bugs (I should probably follow up on those with your colleagues!).
If it helps with diagnosis, then please go ahead and create a support user. The project is named ReadyTech STP-ETL in the ReadyTech space, and the release is 1.1.5 in the Production channel.
This is the output from the Azure DevOps logs when publishing the build metadata for that specific release:
2022-06-07T05:40:05.1344906Z ##[section]Starting: Publish build metadata to Octopus
2022-06-07T05:40:05.1353436Z Task : Push Package Build Information to Octopus
2022-06-07T05:40:05.1353900Z Description : Collect information related to the build, including work items from commit messages, and push to your Octopus Deploy Server.
2022-06-07T05:40:05.1354304Z Version : 5.0.134
2022-06-07T05:40:05.1354517Z Author : Octopus Deploy
2022-06-07T05:40:05.1354852Z Help : Version: 5.2.134. [More Information](https://g.octopushq.com/TFS-VSTS)
2022-06-07T05:40:06.0885379Z [command]/opt/hostedtoolcache/octo/9.0.0/x64/octo build-information --space ReadyTech --version 1.1.5 --file /home/vsts/work/1/octo/857-buildinformation.json --overwrite-mode FailIfExists --package-id stp --server https://readytech.octopus.app/ --apiKey ***
2022-06-07T05:40:06.4904602Z Octopus CLI, version 9.0.0
2022-06-07T05:40:06.8339119Z Detected automation environment: "AzureDevOps"
2022-06-07T05:40:07.6349539Z Found space: ReadyTech (Spaces-22)
2022-06-07T05:40:07.6352540Z Space name specified, process is now running in the context of space: ReadyTech
2022-06-07T05:40:07.6353384Z Handshaking with Octopus Server: https://readytech.octopus.app/
2022-06-07T05:40:07.6853566Z Handshake successful. Octopus version: 2022.2.5111; API version: 3.0.0
2022-06-07T05:40:07.7717206Z Authenticated as: ************
2022-06-07T05:40:07.7814864Z Pushing build information for package "stp" version "1.1.5"...
2022-06-07T05:40:08.2141030Z Push successful
2022-06-07T05:40:08.2275869Z ##[section]Finishing: Publish build metadata to Octopus
Sorry to see you are still having this issue with JIRA integration. With the previous ticket I see our engineer @John_Simons had a look at this for you. I have reached out to him but the is out until tomorrow. Did you make much progress on tis issue with him then?
Meanwhile I logged into your instance and checked logs and the connectivity to JIRA and as you say it all looks good. The ADO side doesn’t seem to be showing errors.
One quick option is to remove the JIRA integration and re-add it. I will caution though that as of right now Atlassian are removing all previous data sent to JIRA by the integration when you uninstall the integration.
This will essentially give you blank slate. If that is not acceptable then do not try this option. Atlassian are currently working on this problem.
Barring this I will be in touch with John Simons our engineer tomorrow when he returns to see if there is progress or a resolution of some sort.
Based on your feedback, I might hold off on uninstalling/reinstalling the Jira plugin; I don’t want to risk messing things up for other projects in our tenant. I’ll wait for John Simons to come back with his response.
I had a chat with our Integrations team about this and we had a good look at the server logs and the setup of the JIRA config on your instance.
The logs seem to be hinting that the user you log into JIRA as, may not have the correct permissions to Read from JIRA the issue its trying to update. This may happen even if the JIRA test connection comes back OK. Permissions on the JIRA end are specific to the project and vary across projects.
The log entry is showing no return when queried by Octopus and its usually because of permissions.
If you can check with your JIRA admin and verify the permissions that would help narrow this one down for us. Perhaps it might be a case of increasing the permission level and see if it affects the access. The log entry below verifies the connection good but it can’t find the relevant JIRA project.