Hi Team,
We have been running builds from Teamcity and GITHUB is our repo. At times I have noticed that the work items (i.e JIRA) doesn’t show up in the Build information for the release version.
Below is a screenshot where ADBF-7544 is the JIRA number for a commit.
Thanks,
Venkat
Hi Venkat,
Thanks for getting in touch! I’m sorry to see you’re hitting this issue unexpectedly. Would you be willing to send through a copy of your build logs for us to get a better look into what could be happening? That should hopefully contain enough information to spot what’s causing this. Feel free to upload it to this generated upload link.
Best regards,
Kenny
Thanks Kenneth for the response. I have uploaded the logs.
Thanks,
Venkat
Hey @venkatakrishnarao.amaripalli,
Thanks for sending over your task log. Can you send over your Teamcity build log?
For the issues to appear in Octopus, they need to be pushed as part of the build information in your build pipeline. Generally, your build process would include all the steps for packaging your code, then it would push the package to Octopus, and the last step is to push the build info to Octopus for that package. That last step contains all the commit and work item data (assuming you’re using JIRA issue keys in your commits, so they show up in your GitHub repo). Once that build info is pushed to Octopus, your packages display the work items.
Best,
Brent
Hi Brent,
I have uploaded the Teamcity logs as well.
Thanks
Venkat
Hey @venkatakrishnarao.amaripalli,
Thanks for sending over that build log. Your build process looks good. I did notice that your build info contained the commits for your build but no work items. When making commits to GitHub, are you putting the Jira issue key in the commit message? Is ADFB-7544 a Jira work item?
It appears that your work item links are not making it to your build server, so they are not present when you push the build info to Octopus. Your build info only contained the commit info, no data on work items. It may be worth reviewing our Jira integration docs to ensure your build information configuration is set up correctly.
{
"BuildEnvironment": "TeamCity",
"Branch": "refs/heads/develop",
"BuildNumber": "2209.13.12-dev",
"BuildUrl": "https://BUILDSERVER.com/viewLog.html?buildId=4603401",
"VcsType": "Git",
"VcsRoot": "https://github.com/REPOADDRESS.git",
"VcsCommitNumber": "0cd513dba2538fc3c40d6df7677237355f8253c0",
"Commits": [
{
"Id": "0cd513dba2538fc3c40d6df7677237355f8253c0",
"Comment": "ADFB-7544\n\ntest proc\n"
},
{
"Id": "9ede0e1e31228f200b80e5aefa68442623658fef",
"Comment": "Datical automatic check-in at 2022-08-12-12-12-57\n"
}
]
}
Best,
Brent
Hey Brent,
ADFB-7544 is the JIRA work item and this is been passed as part of the commit message but still it wouldn’t show up in the Build Information.
Thanks,
Venkat
Hey @venkatakrishnarao.amaripalli,
After talking with a colleague, I’d like to confirm that you have your Jira integration enabled and configured in Octopus? Do work items show up under any other packages? If they do, can you try running this curl command from your Octopus server to ensure Octopus can reach out to Jira?
curl.exe --user "your.email@domain.com:YOUR_API_KEY" --header 'Accept: application/json' --url 'https://yoururl.atlassian.net/rest/api/2/issue/ADFB-7544'
Feel free to send over screenshots of your Jira integration config settings.
Best,
Brent
Hey @venkatakrishnarao.amaripalli,
I just spoke with @jason.gallup after your call and wanted to keep troubleshooting your Jira issue.
Can you try running these two curl commands using the same Jira Token used in your Jira integration setup for Octopus and send screenshots of the output from each curl?
curl.exe --user "your.email@domain.com:YOUR_API_KEY" --header 'Accept: application/json' --url 'https://yoururl.atlassian.net/rest/api/2/issue/DBR-2493'
&
curl.exe --user "your.email@domain.com:YOUR_API_KEY" --header 'Accept: application/json' --url 'https://yoururl.atlassian.net/rest/api/2/issue/DBR-2150'
If you could also send over screenshots of those issues in Jira (DBR-2150 & DBR-2493) so we can compare why one works, and another doesn’t, that would be great.
If you’d prefer, we can also jump on a quick zoom call to go over that info. Let me know your preference.
Best,
Brent
Hi Brent,
Here are the outputs. Let me know if you want to connect I am available this afternoon.
11:32:49 Info | StatusCode : 200
11:32:49 Info | StatusDescription : OK
11:32:49 Info | Content : {“expand”:“renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations,custo
11:32:49 Info | mfield_10021.requestTypePractice”,“id”:“593841”,“self”:"https://lplfinancial.atlassian.net/rest/api
11:32:49 Info | /2…
11:32:49 Info | RawContent : HTTP/1.1 200 OK
11:32:49 Info | Timing-Allow-Origin: *
11:32:49 Info | X-Arequestid: f855285c9c9f12bfbd70171021e9ac82
11:32:49 Info | X-Aaccountid: 5ef387ca1f3bd90ab2a7c3c3
11:32:49 Info | Vary: Accept-Encoding
11:32:49 Info | X-Envoy-Upstream-Service-Time: 322
11:32:49 Info | Expect-Ct: r…
11:32:49 Info | Forms : {}
11:32:49 Info | Headers : {[Timing-Allow-Origin, *], [X-Arequestid, f855285c9c9f12bfbd70171021e9ac82], [X-Aaccountid,
11:32:49 Info | 5ef387ca1f3bd90ab2a7c3c3], [Vary, Accept-Encoding]…}
11:32:49 Info | Images : {}
11:32:49 Info | InputFields : {}
11:32:49 Info | Links : {}
11:32:49 Info | ParsedHtml : mshtml.HTMLDocumentClass
11:32:49 Info | RawContentLength : 12895
11:32:49 Info | StatusCode : 200
11:32:49 Info | StatusDescription : OK
11:32:49 Info | Content : {“expand”:“renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations,custo
11:32:49 Info | mfield_10021.requestTypePractice”,“id”:“593841”,“self”:"https://lplfinancial.atlassian.net/rest/api
11:32:49 Info | /2…
11:32:49 Info | RawContent : HTTP/1.1 200 OK
11:32:49 Info | Timing-Allow-Origin: *
11:32:49 Info | X-Arequestid: f1e86a4007879a2de6a7ec5c05f202b7
11:32:49 Info | X-Aaccountid: 5ef387ca1f3bd90ab2a7c3c3
11:32:49 Info | Vary: Accept-Encoding
11:32:49 Info | X-Envoy-Upstream-Service-Time: 273
11:32:49 Info | Expect-Ct: r…
11:32:49 Info | Forms : {}
11:32:49 Info | Headers : {[Timing-Allow-Origin, *], [X-Arequestid, f1e86a4007879a2de6a7ec5c05f202b7], [X-Aaccountid,
11:32:49 Info | 5ef387ca1f3bd90ab2a7c3c3], [Vary, Accept-Encoding]…}
11:32:49 Info | Images : {}
11:32:49 Info | InputFields : {}
11:32:49 Info | Links : {}
11:32:49 Info | ParsedHtml : mshtml.HTMLDocumentClass
11:32:49 Info | RawContentLength : 12895
Thanks,
Venkat
Sure Brent, that works
Great, let’s meet at 430pm EST. I will DM you the meeting link.
Best,
Brent
Hey @venkatakrishnarao.amaripalli,
I have an update from engineering for you. They mentioned that the work item data, like a lot of other data, gets snapshotted against a release when the release gets created. If you’re looking at Build Info or Packages feed in the Library, then you’re looking at live calls to Jira, but on a release, the calls got made at release creation, and you’re seeing the snapshotted results. That is why some links appear, and others don’t. During their release creation, the data wasn’t pulled from Jira. If you’d like to confirm that your items are appearing, you could check those releases for the packages used and check them in your package library for that build info.
As Jeremy mentioned on our call, it may be worth testing those curl commands from each server node to ensure they can all reach Jira without issue.
Best,
Brent
Hey @venkatakrishnarao.amaripalli,
To go along with the information Brent gave you, I believe your next best step to figure out why some work items aren’t showing up would be to find a release with a work item missing, find out when that release was created, then check the 3 nodes’ server logs for that time to see the corresponding error for that work item. I believe you will only have logs from the last ~7 days on your servers due to how we roll over logs so you will need a somewhat recent release.
Please let us know if that helps.
Best,
Jeremy
Hi @jeremy.miller and @brent_kinney ,
Below is the warning that I am seeing in the log for one of the release build information failing to fetch the Work Items.
Log - 2022-10-07 06:34:35.2447 11204 8193 WARN Failed to retrieve Jira issues ‘LBS-6660, 2022-10’ from https://lplfinancial.atlassian.net. Response Code: BadRequest (Reason: Bad Request).
Looks like it is treating 2022-10 in “Datical automatic check-in at 2022-10-07-09-15-55” commit message as JIRA number which becomes a Bad request.
Can you check your regex and see if you are using a valid regex for JIRA?
Thanks
Venkat
Hey Venkat,
Thanks so much, this is exactly what we needed.
Thanks for the details. I’m gonna get this back to our engineers to have them take a look.
We’ll keep you in the loop but feel free to reach out in the mean time.
Best,
Jeremy
Hey Venkat,
I had a long discussion with the developers about this last night. The issue is, with Jira On-Premise you can actually set your Project Key to be numbers only, so we have to account for that. So in your case having the date 2022-10-07-09-15-55 will have our parser pick up 2022-10 as a potential Jira Issue because in some scenarios it might be a valid Jira Issue.
We had some discussion on possible solutions for this (for our users who don’t use numbers only in their project keys) and we believe in the future we’ll have it so you can define in the Jira Settings in the Octopus Portal what your Jira Project Key format is. Such as letters only, letters and numbers, or numbers only. That way our regex will key off of this and we won’t have issues like you’re seeing here.
However, since this is not an insignificant change it isn’t likely to get implemented quickly. Now that we have the root cause of what’s causing your issue, in the short term would it be possible to have the date format in commits use dots? Such as 2022.10.07.09.15.55 rather than 2022-10-07-09-15-55.
I know this isnt the best news but I hope you can understand the reason we’re in this situation.
Here is an issue you can follow for updates: Jira work item retrieval failing with bad request due to dates in the commits. Error is "Failed to retrieve Jira issues ‘ISS-555, 2022-10’ from https://serverurl.atlassian.net. Response Code: BadRequest (Reason: Bad Request)." · Issue #7844 · OctopusDeploy/Issues · GitHub
Please let me know if that helps or if you have any questions.
Best,
Jeremy
Hi Jeremy,
Thanks for the explanation. Unfortunately we cannot remove the Date and as you are seeing the message in the commit, it is an automatic commit done by another DB tool which is not in our hands.
It will be really great if we can have a fix as mentioned above at the earliest.
Also, is there a way to just pass the JIRA to the workitem instead of relying on the logic that determines it?
Thanks,
Venkat
Hey Venkat,
The engineers have been doing a bit of a deep dive on this and due to some recent findings from last night they were curious if you could please run the curl above that emulates the Jira call that Octopus makes on all 3 HA nodes for a known working Jira Issue? Once you have done that can you please share the results of all 3 HA nodes so I can pass that back to the developers?
They are thinking the date issue is a red herring.
We found a bug in the code that should be stopping releases from being created if there’s an issue with the Jira connection which will be getting resolved.
Once I have the results I can send those back to the developers along with your feedback.
Please let me know if you have any questions.
Best,
Jeremy