Release issue

[endashaw.adane]

Hi Team,

Recently I noticed some issue in Octopus. We release package 7.7-30-bau-302d9de from Jenkins, however, in Octopus same release created but what is getting deployed is 7.7-27-bau-302d9de and 7.7-30-bau-302d9de kept in queue. This trend will continue still. So, every time we create new release, octopus is keeping it in the queue and deploying another one. I’ve attached the screenshot for your reference

Regards,

Endashaw

[Justin_Walsh]

Hi @endashaw.adane!

Thanks for reaching out, and sorry to hear that you’re having issues with your deployments. I was just wondering if I could get some more details of your setup? Do you have any auto-deployment triggers on this project’s lifecycle?

One thing that stuck out to me is that your package names aren’t strictly SemVer compliant, which doesn’t factor metadata in for versioning, so 7.7-1-bau-1234 and 7.7-100-bau-4321 are both considered version 7.7 - changing the 7.7-27 to a 7.7.27 would bring it into compliance with Semantic Versioning.

I hope this helps, and look forward to hearing from you regarding the above questions.

[endashaw.adane]

Hi @Justin_Walsh,

Thanks for your response. No I’ve not enabled auto deployment trigger. I am changing to use the semver. Instead of using 7.7-31-bau-68165c3 I am using 7.7.31-bau-68165c3. I am closely monitoring this.

Regards,

[endashaw.adane]

@Justin_Walsh ,

I did as suggested and able to create the release. e.g. release 7.7.32-bau-b9bf391 created, but in octopus that is release is kept in queue and another release 7.7.29-bau-b9bf391 (same package) is getting deployed. Can’t understand where and how Octopus deploying/doing this.
If you open, 7.7.29-bau-b9bf391 you will see the actual deployment is for 7.7.32-bau-b9bf391. That is strange. how is the release and version are different.

Attached some files for your reference

Regards,

Endashaw

[endashaw.adane]

may be the below setting is the one causing the issue

[endashaw.adane]

@Justin_Walsh ,

I changed release versioning but still same. every time a new release is pused from Jenkins, octopus is creating additional release…with the same versioning.
here is another one…what I pushed is 7.7.33. but Octpus is also creating 7.7.30

[Daniel_Fischer]

Hi Endashaw,

Thanks for getting back. I’m stepping in for Justin who is currently offline as a member of our US team.

I think we will need some further information to better understand what could be causing this issue to occur.

Would you be able to sign into your Octopus organization and upload your Jenkins build logs for a release which had this issue? This log will have detailed information about the commands being sent to Octopus and could help to identify the issue.

Furthermore, in the screenshots you attached, I can see that you’re using the default Release Versioning template. It looks like you intend to have the release number be the same as the package version number. If this is the case, you could try selecting the Use the version number from an included package. Though, if your releases are created by commands from Jenkins, it may not have much of an impact on your issue.

Looking forward to getting to the bottom of this.

Best regards,
Daniel

[endashaw.adane]

Hi @Daniel_Fischer ,

Thanks for looking this issue. Yes, I’ve switched to use the version number from an included package. but still same. I’ve uploaded the build log as reqeusted

Regards,

Endashaw

[paul.calvert]

Thanks for that Endashaw.

Could you check one more thing for us too?
Within the Octopus web portal, if you select this project and navigate to the Triggers page.

On the right-hand side, there will be a section for Automatic Release Creation. Is there anything configured there?
e.g.

[endashaw.adane]

Hi @paul.calvert ,

No. there is nothing configured there. By the way, we are not using the builtin repository.

[paul.calvert]

Thanks for checking that.

The automatic release creation feature is the only way that Octopus can create a release itself, as this isn’t configured it does suggest that something external is creating the second release.

There are a few more items we can check to try and narrow down where this is coming from.

Firstly, would you be able to download and run the Octo CLI manually with the same command that Jenkins is using? You will need to increment the version number to one that doesn’t exist yet. This test will allow us to narrow down where the problem lies by removing Jenkins from the process.
e.g.
Octo.exe create-release --version 7.8.36-bau-8239513 --channel Bug-fix --deployTo DEV-1 --progress --project UMS --server ****** --apiKey ******** --space Spaces-2 --deploymentTimeout 00:30:00

The other item to check would be the audit record for the duplicate release. If you navigate to Configuration > Audit and use the filters Event Category: Document Created and Document Type: Release along with selecting the relevant project you should see a list of the release creation events.
You can then select the events to see what initiated the creation.
e.g.
This release was created via the portal

[endashaw.adane]

@paul.calvert ,

I run octo.exe and only one release is created. but note that I am using Octopus Deploy plugin in Jenkins.

I checked also the audit…there are some duplicate release though the last 7 digits (comit hash) is different. Not sure. the underlined releases in the image are created on same date but different time. and you can see they have different commit hash. Why the first three digits repeated?

[paul.calvert]

Thanks for running that test. The Jenkins plugin is essentially a wrapper for octo.exe so this test helped rule out any bugs with octo.exe or Octopus.

This does suggest that the duplicate release is being created due to his Jenkins has been configured.
The build log you sent across did only have the single create release task in there, but is it possible that Jenkins is triggering multiple builds at the same time?
If you compare the timestamps of the recent builds in Jenkins I’m wondering if they match the duplicate release creation times?

[endashaw.adane]

@paul.calvert ,

Thanks for the feedback. I dont see anywhere Jenkins is triggering duplicate builds. Can we clean the release and start from scratch? what is the best way to do?

Regards,

Endashaw

[Kenneth_Bates]

Hi Endashaw,

Thanks for following up and for all the details so far. I’ll jump in for Paul as he’s now offline as part of our UK-based team.

This is certainly a strange issue! My suspicion as well is that multiple builds are being triggered in Jenkins at the same time, as Paul mentioned. If you look at the audit log, using the advanced filter to filter by Document created event category and Release document type, do you see these duplicate releases created in the same way? I’m hoping that will help narrow down what is actually causing this, so we can try to address the root issue.

Best regards,

Kenny

[endashaw.adane]

Hi @Kenneth_Bates ,

Audit does not show clearly why the duplicate/the other release is cretaed. As you can see in the screen shot attached, 7.11.48 is the correct release, but after some mins, another release 7.11.45 is created. I am 100% sure it is not related to octpus. b/c I was following the build rocess, and sudenly saw that the package is pused in to Nexus. So this is b/n Jenkins and Nexus.

Regards,

Endashaw

[endashaw.adane]

@Kenneth_Bates ,

Found out the issue…another Jenkins job is running and that is the root cause. Thank you all for your time!!!

Regards,

Endashaw

[Kenneth_Bates]

Hi Endashaw,

Thanks for following up and letting us know you found the issue! Don’t hesitate to reach out anytime if you come across any other questions or concerns.

Best regards,

Kenny