Hi
We are pushing Docker images to Docker Hub and then reference the image id inside a Run Container step in Octopus. How do I push build information to Octopus so that it’s visible on the release page?
I’ve read this thread but it was for TeamCity.
Thanks
Best regards
Joakim
Hi Joakim,
Thanks for getting in touch! Similar to the thread you linked to discussing our TeamCity plugin and its built-in build information task runner, our Azure DevOps extension has a built-in task called Push Package Build Information to Octopus that you can add to your ADO process. The following Azure DevOps extension documentation page covers the process of configuring the extension including this build information task.
I hope that helps! Let me know if you have any questions or concerns going forward. 
Best regards,
Kenny
Hi Kenneth
Thanks for quick response. I’m actually using that said package in this particular case since beside from build a Docker image, I’m also producing a settings file that is pushed as a package.
But there is still no information available in Octopus. I want to be able to push build information tied to the Docker image as well, but that isn’t pushed as a package to Octopus rather pushed to Docker Hub and later retrieved.
Looking at the latest build, I see that the package step failed but didn’t signal error:
(node:81557) UnhandledPromiseRejectionWarning: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1049:34)
at TLSSocket.emit (events.js:182:13)
at TLSSocket._finishInit (_tls_wrap.js:631:8)
(node:81557) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:81557) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
What might causing that? All other steps related to Octopus works as intended.
# azure-pipelines.yaml
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: $(dotnetVersion)
displayName: Install dotnet
condition: succeededOrFailed()
- task: OctoInstaller@5
inputs:
version: '*'
displayName: 'Octopus install latest'
- task: OctopusMetadata@5
displayName: Push build information
inputs:
OctoConnectedServiceName: 'Octopus'
Space: 'Default'
PackageId: Api.WebApi.AppSettings
PackageVersion: '$(Build.BuildNumber)'
Replace: 'false'
Octopus: 2022.1.2232
AzDo:
##[section]Starting: Octopus install latest
==============================================================================
Task : Octopus CLI Installer
Description : Install a specific version of the Octopus CLI
Version : 5.0.134
Author : Octopus Deploy
Help : Version: 5.2.134. [More Information](https://g.octopushq.com/TFS-VSTS)
==============================================================================
Downloading: https://download.octopusdeploy.com/octopus-tools/9.0.0/OctopusTools.9.0.0.linux-x64.tar.gz
Extracting archive
[command]/bin/tar xC /azp/agent/_work/_temp/f7fea7b0-230d-4d94-a1f2-0200644fc534 -f /azp/agent/_work/_temp/64ab3e32-25c7-428d-b275-2df0f420ad75
Caching tool: octo 9.0.0 x64
Found tool in cache: octo 9.0.0 x64
Prepending PATH environment variable with directory: /azp/agent/_work/_tool/octo/9.0.0/x64
##[section]Finishing: Octopus install latest
##[section]Starting: Push build information
==============================================================================
Task : Push Package Build Information to Octopus
Description : Collect information related to the build, including work items from commit messages, and push to your Octopus Deploy Server.
Version : 5.0.134
Author : Octopus Deploy
Help : Version: 5.2.134. [More Information](https://g.octopushq.com/TFS-VSTS)
==============================================================================
(node:81557) UnhandledPromiseRejectionWarning: Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1049:34)
at TLSSocket.emit (events.js:182:13)
at TLSSocket._finishInit (_tls_wrap.js:631:8)
(node:81557) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:81557) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
##[section]Finishing: Push build information
Hi Joakim,
Thank you for following up and providing that level of detail! I’m sorry to see you’re hitting this unexpected issue.
It’s possible this specific error is a result of Azure DevOps working on deprecating TLS 1.0 and 1.1, along with some weak cipher suites in TLS 1.2, so I think that will be the best thing to first try to confirm/rule out. Microsoft built a readiness checker that I’ll link below which includes a script to run which should help rule this in or out as a possibility.
In addition, during some discussion with a colleague it looks possibly related to another extensive thread on our forum that boiled down to a node issue preventing users from acquiring local issuer certificates when behind a corporate firewall.
I hope that helps narrow down the search, and I look forward to hearing back!
Best regards,
Kenny
Hi,
I ran the code and no errors was reported. Some warnings regarding applications targeting framework [3.5, 4.5.x] was detected but I doubt it has anything to do with this. Do you agree?
I downgraded installer and meta data task to version 4 and in that version an error is reported when the local issuer certificate error is thrown. So most likely a bug in version 5 since the task fails but the pipeline succeeds.
The steps for pushing package and creating release are both at version 4 and they work as intended. Only difference in my pipeline file is that those are part of a template and runs in a another job. Can this affect the pushing of metadata?
Update:
From Check the entire package ID
If you find your work items or other build information aren’t showing up in your releases, make sure your package ID as shown in the release is the exact same as it is found in the Library ➜ Build Information section. Some package ID values, particularly those found in external feeds must include the repository. For example, if you were pushing build information for the docker image
octopusdeploy/worker-tools, the value for the package ID needs to include the repository name ofoctopusdeploy/as well as the name of the docker image, not justworker-tools.
But the Docker image isn’t published as a package, so how do I attach build meta data to it?
Thanks
Hi @j.carselind,
Thanks for getting back in touch and for the detailed investigation you’ve done.
When it comes to using docker containers as execution containers for process steps, we don’t include these as packages in the release. At least, not in the same sense as a package that is ‘deployed by’ or ‘referenced in’ a step.
I can’t say for certain why this is, perhaps someone else with more knowledge on our development process would be able to explain why.
I can pose the question internally to get more accurate information but I believe that execution containers aren’t usually modified in the same way or as often as a typical package.
That being said, it is possible to reference this package inside a “Run a Script” step or other package transfer step in order to force the build information to show on the release page.
As long as you have an entry for “octopusdeploy/worker-tools” inside Library → Build Information, referencing this package elsewhere in the deployment process should allow for the Build Information to be displayed.
I’ll attach some screenshots below to explain further:
Library → Build Information:
Inside the step:
On the process screen:
On the release screen:
I hope this helps! Please let me know if I’ve missed anything or if you have any further questions/concerns.
Kind Regards,
Adam
Hi Adam
So it’s not enough to be “referenced” from within a Run container step? I need to add a fake step that then actually reference the build information package, if I understand it correctly?
Currently having issues with using the meta data task as described in previous posts, but the rest of the Octopus task works as expected.
As soon as I can get it to work I’ll try adding the fake step and hopefully it shows up.
Thanks
Hi @j.carselind,
Apologies, I was under the impression that you were using the worker-tools container as an execution container, rather than via the “Run a Docker Container” step.
That step should correctly reference the package in the same manner, and build information should be displayed if you have referenced the correct ID and Version inside Library → Build Information.
If you create a release with the container referenced in the Run a Docker Container step via the Octopus UI, you can confirm the container is referenced as a package before the release is created:
If the case is that the package shows up on this screen or on the actual release screen but no build information is displayed, then it’s likely that your build information in Library → Build Information is tied to a different version of the container.
Apologies once again and I hope this helps explain better.
Kind Regards,
Adam
Thanks for all your help. I resorted to using the NODE_TLS_REJECT_UNAUTHORIZED=0 workaround and now it works and the data is displayed! I can see the VcsCommitNumber inspecting the response which is what I’m after.
Once again thanks
Hey @j.carselind,
No worries at all, glad we could help get you to where you wanted to be and thanks for letting us know!
If you run into any other issues in future, don’t hesitate to reach out again.
Kind Regards,
Adam
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
