I have an Octopus deployment that is integrating with Atlassian’s BitBucket Cloud and Jira Cloud. I am using BitBucket Pipelines to create and deploy an image to AWS ECS, and as part of the deployment, I am publishing build information and then creating a release.
When the pipeline runs, if there is a Jira issue referenced in the build information, then the create release step fails with the following error:
Channel: 'Development' (this is the default channel)
# Name Package Name Version Source Version rules
--- -------------------------------- -------------- ----------- ------------------ -------------------
1 Create AWS ECS task definition stp-api 0.0.1.232 Latest available Allow any version
Creating release...
There was a problem with your request.
- Jira: Failed to retrieve Jira issues 'SC-76' from https://readytech.atlassian.net. Response Code: BadRequest (Reason: Bad Request)
Error from Octopus Server (HTTP 400 BadRequest)
Exit code: -7
✖ Command: create-release failed. Please see the output for further details.
If I go to the Jira configuration settings page in Octopus, I can verify that the Jira connection settings are okay using the Test buttons, and I can also see that the build information is being correctly pushed to Octopus.
Thanks for your quick response. The problem is that the ticket referenced (SC-76) does exist. Are there permissions involved in the Jira <-> Octopus integration, and can we check those?
I’m sorry to see that you are facing this issue. It’s good to see that the Jira Issue is being recognised in the Octopus logs and there is an attempt to match the issue up with Jira. This rules out a lot of potential problems.
Can I clarify what version of Octopus you are using?
Can you also clarify what version of the Octopus Deploy Marketplace extension you have installed on Jira?
Have you upgraded the marketplace app or reconfigured anything on either end (Jira or Octopus)? Sometimes, when there are issues with Jira integration, we get the user to uninstall the Marketplace app, remove the details from Octopus and then reconfigure the connection. This has worked a handful of times to fix issues when nothing seems to be incorrectly configured.
I can also see that the build information is being correctly pushed to Octopus.
Does the “Work Items” field populate with the correct link?
Also, is your Environment set with a Jira Environment type? You can check this via “Infrastructure” → “Environments” then select Edit from the burger menu next to the environment name.
There are a handful of other troubleshooting steps available here:
Please, let me know if this gets you any further, then we can dig a bit deeper.
We are on Octopus Cloud - Version 2021.3 (Build 8275); the Octopus plugin is 1.0.5-AC.
Build information is not showing the Work Items. Here’s what the build server logs show (this is using the Octopus Deploy pipe for BitBucket):
Digest: sha256:e23751377a0c7a8d9b321ad2e77e7822bb6c086fc8c2747bd9b7ded95c9b2994
Status: Downloaded newer image for octopipes/octopus-cli-run:0.26.0
INFO: Running: octo build-information --package-id=stp-api --server=$OCTOPUS_SERVER --apiKey=$OCTOPUS_APIKEY --file=octopus.buildinfo --space=Aussiepay --version=0.0.1.232
Octopus CLI, version 7.4.3467
Detected automation environment: "BitBucket"
Found space: Aussiepay (Spaces-2)
Space name specified, process is now running in the context of space: Aussiepay
Handshaking with Octopus Server: $OCTOPUS_SERVER
Handshake successful. Octopus version: 2021.3.8275; API version: 3.0.0
Authenticated as: David Keaveny <david.keaveny@readytech.io>
Pushing build information for package "stp-api" version "0.0.1.232"...
Push successful
Meanwhile, if I look at that release in Octopus and check the build information, then I can see the following:
Create AWS ECS task definition:stp-api(stp-api) version 0.0.1.232
Published: Tuesday, 14 December 2021 4:04 AM +00:00
Platform: linux amd64
Build Information
Build Environment BitBucket
Build 232
Commits 819edbc Merged in feature/SC-76-fix-authentication-bug (pull request #13)
Work Items
Environments are correctly mapped (e.g. in Octopus, Development environment is mapped to development environment in Jira), and I can see deployments in Jira, and in Jira, those deployments are linked back to their tickets.
I have other projects which are successfully sending through Work Items. They are all using the same Octopus and Jira instances, but most of them are building with on-premise TeamCity and using its build information plugin, whereas this one is using Atlassian Bitbucket Pipelines - maybe that is a factor? And they are using different Jira projects (which is why I asked about permissions). That suggests at least that the Octopus Deploy plugin for Jira is working.
As you are a Cloud user the fix (Azure DevOps at least) has already been applied so there may be specific Bitbucket issues that were not addressed.
It does look like the key factor is the Bitbucket Pipeline. Has the build info ever appeared in JIRA when using the Bitbucket pipeline create-release? I am trying to establish if its a new issue or the integration is just not working.
I see one of our team has commented on the GH issue and I can note this ticket there. I will pass this along to our Dev team in the meantime to take another look.
No, this is our first time using BitBucket Pipelines to integrate with Octopus Deploy and Jira. I am aware that the Octopus pipe is in beta at the moment, so it could well be a bug in the code there. I can try switching to use the more generic Octopus CLI tool and see if that makes a difference, or we can see if we can drive the bug out of the code through further investigations.
Hi David,
Even though this issue has been fixed in the Cloud your instance is on an older version than the one the fix came in.
I am asking our Cloud team if you can be upgraded sooner rather than later to get the fix applied for your version. This can be done at the next available maintenance window.
Thank you for organising the update of our instance, I can see we are now running on build 9562.
The good news is that I’m not getting an error when I include a work item ID in my commit messages; the bad news is that there are no work items coming through in the build information step. I don’t know if you want to close this ticket, and open a new one, or just keep going here?
I’ve had a look at the identifier issues in Jira; in some cases, the ticket has been moved from one project to another and has therefore acquired a new key. For instance, EP-7302 (the first one you highlight) is now known in Jira as AI-588, so that sounds like it might be more of a Jira issue than an Octopus Deploy one. Some of the others are blatant typos - for instance, DES-92 should actually be DE-92. Others just don’t exist at all - maybe issues that were actually deleted. The accout definitely has access to all the tickets.
The issues I am particularly interested in are in the SC project - this is the only project that uses BitBucket Pipelines to build and deploy; all the others use our on-premise TeamCity server to build and deploy. I create a build this morning to verify that the new Octopus instance would indeed fix the issue and referenced SC-46 in the commit message (and that shows in the build information commit section) but doesn’t appear in the work item section. Would you be able to check for SC-46?
Are those logs visible anywhere for users like myself, or are they an internal-only feature for Octopus support?
That is good to know that some issues have been renamed or mistyped.
Regarding SC-46, I can’t see anything in the logs regarding this one!
Do you give me authorisation to login to your instance and have a look? What is the package name?
Hi @rjunruh
Thanks for letting us know.
I am reaching out to our Dev team to see if the Server version is ready to be released, or maybe a version we can provide for you with the fix applied.
I’ll get back to you as soon as I get confirmation.
Hi @rjunruh
Our Dev team say the next drop of Octopus Server will be around 2 weeks from now - most likely version 2021.3.9562.
We could provide a custom build but to be honest that might be more trouble than its worth as it may vary enough from the next release so as to potentially cause upgrade issues. I would recommend waiting for the next official release and I’m pretty sure it should be out before the end of January at the latest.
