We use TeamCity, that makes builds and publishes build information to Octopus Cloud.
It works as expected for NuGet packages. But one of our projects consists only of a Docker image and I cannot make build information for it to appear in Octopus. Here are the settings:
The docker image has a version %build.number%
The docker image repository is connected to the Octopus instance as an external feed.
The “OctopusDeploy: Build Information” step goes after the docker push and before the octopus create release steps. It uses the docker image name as Package ID and %build.number% as package version.
Thanks for reaching out. Just to be sure it is working as expected, I was able to do a quick reproduction and was able to get build information to populate for a docker image on an external feed.
Would you be able to provide the commands you are running to push build information, as well as screenshots of:
Your external feed test, searching on the docker image you want to use
Could you also please provide the command you’re using to push the build info as well as the build info file?
For reference: octo build-information --apiKey="API-" --server="[http://octopus01.home.local](http://octopus01.home.local/)" --space="Default" --file="octopus.buildinfo" --package-id="harrisonmeister/rolling-deploy-example" --version="0.0.3"
Some of the above doesnt relate to each other but I wanted to give you examples of all of the info I needed. Please let me know if you have any questions.
Now I probably see the reason — we don’t have the file with the build info. The “OctopusDeploy: Build information” step in TeamCity does not mention it. But, apparently, it’s required for that step, right? What is the expected location for the build info file on that step? Is there a tool or plugin for TeamCity to generate the Octopus build info file?
Thanks for the information. The teamcity stuff looks okay so far.
That release says theres no packages associated with it. Is that the project where you are deploying the docker image? I believe there should be a package listed there like in my example above.
Also, when you go to build information tab in library, what do you see? Do you see an entry for smartinmedia.azurecr.io/patho-viewer ? Can you send a screenshot of your build info section of the library?
I do not really get, what does it mean to deploy a docker image to a project.
In the Octopus deployment process we use several RAW KUBERNETES YAML steps to deploy the app into a K8s cluster. There is no relation from the docker image to the project, other than the YAML source code.
Here’s the screenshot from the build information tab:
I want the build information to appear on the release page and then get promoted to Jira via the corresponding integration. The same way as we have this for other projects (with NuGet packages).
I did some tests on my own and I see that when you reference the package in the create-release command, the build info doesnt show up, however the package does show up within my release, just the link between the build info seems to not work. I was doing my testing on 2020.2.13, which version are you currently on?
Can you please try adding the dummy script step and reference the package and manually create the release in the GUI just to see if your build information portion is working and we can dig into the other section after?
Another thing, that really confuses me, is that the package reference is specified in a deployment step. Does it mean, that during deployment the latest version of the package from the feed will be used? Or the package version is set for the release and this version will be used at any time when the release is deployed? If the package version is linked in the release and cannot be changed, then why a package reference is needed in a build step — wouldn’t it be more clear to use the package from the release?
I’m glad to see that it’s working at some capacity so far. Were you able to achieve these results by manually creating the release in the Octopus GUI, or were you able to get these results with the create-release command?
“Does it mean, that during deployment the latest version of the package from the feed will be used?”
The version of the package that will be used is determined by the one you select when creating the release. You are correct that once you choose a package version for a release, whenever that specific release is deployed you will use the same package version and that won’t change.
“If the package version is linked in the release and cannot be changed, then why a package reference is needed in a build step — wouldn’t it be more clear to use the package from the release?”
Could you please clarify this question a bit for me?
Were you able to achieve these results by manually creating the release in the Octopus GUI, or were you able to get these results with the create-release command?
I achieved that via the TeamCity plugin (i.e. dotnet Octo.dll create-release).
Could you please clarify this question a bit for me?
There are multiple places for adding a package reference in a release:
In the release itself
In a build step inside the project
I have to reference the same package in both places. And they both seem mandatory. Wouldn’t it be more convenient to have only the reference in the release? Then I would not need a dummy deployment step.
In my testing when trying it with the create-release method, the package would show up, but build info would not populate until I later manually created a release. I need to do more testing on this behavior. Ideally this should work by itself, then you wont need to create the dummy step to get it in your release.
I will do some testing and get back to you. Please feel free to reach out in the mean time with any questions regarding this.
I apologize for taking so long to get back to you on this one. I did have some talks with colleagues on this one and they said that it is intended behavior for the package to not show up unless it’s also referenced inside of a step within the project. The --package paramater is only for selecting the version of the package to be used within steps where the package is referenced.
This does seem like a fringe case in which I could see the benefit of not having that requirement, but the intent is to treat docker like any other package in the feed.
Sorry I don’t have better news for you, but hopefully the dummy step is not too cumbersome for you to get build information associated with your releases.
Please reach out if you have any other questions or concerns regarding this.
Thanks for the update.
A dummy step is fine. It just confused me, that there are two different places for referencing packages.
Do I understand now correctly, that a reference from the process, is, actually, a feed reference, not a package reference? And the package of the specific version is referenced only for a release?
Yeah the documentation on the --package parameter could use a little more specificity to say that it’s only for selecting a version of a given package as it can be a bit misleading.
You are correct that the reference within the process steps is just indicating which package ID(or in your case, docker image) should be used, and when creating the release you will specify the version of the package you defined in the process to be used. It’s a two part process.
Please let me know if that answered your question or if I misunderstood the question.