This is because we’re deploying different flavors of the package (think: Debug vs Release) to different environments.
Is it possible to push build information for a “dynamic” Package ID (containing a variable) so that it shows up in the release notes?
The following is not accepted by the CLI:
$ octo build-information --package-id=StackExchange.Website.#{Configuration} ...
...
Pushing build information for package "StackExchange.Website.#{Configuration}" version "2.1.12"...
There was a problem with your request.
- The package ID contains invalid characters. Examples of valid package IDs include 'MyPackage' and 'MyPackage.Sample'.
Error from Octopus Server (HTTP 400 BadRequest)
...
Update: it looks like pushing the same build information for all configurations…
$ octo build-information --package-id=StackExchange.Website.Debug ...
$ octo build-information --package-id=StackExchange.Website.Release ...
… and adding a release note like
#{each package in Octopus.Release.Package}
Package: #{package.PackageId} #{package.Version}
#{each commit in package.Commits}
[#{commit.CommitId}](#{commit.LinkUrl}) - #{commit.Comment}
#{/each}
#{/each}
somehow works: on the release page, although it says “Package will be resolved during deployment” in the “Packages” section, the “Release notes” section renders the commits of the StackExchange.Website.Release package.
It would be interesting to understand what is going on here and if we’re doing this right.
To better explain what might be happening with the release notes, could you tell me how the Configuration variable is scoped? I believe you mentioned that it changes based on the environment, but I didn’t want to assume.
Thank you for getting back to me with that information. I have an idea of what might be allowing you to get the release notes you’re seeing, but I’d like to do a little more testing on my end before I can say for sure.
Good news, I was able to reproduce your scenario locally and get the same results with my build information showing for the release when using a dynamic package.
However, I’m not entirely sure how this is working. Since your variable for the dynamic package is scoped to the environment level, Octopus shouldn’t evaluate the variable until the deployment time of that release.
I think Octopus is guessing which value of that variable should be used and picking one at random, allowing you to see the build information before deployment. I want to confirm with the engineers to find out for sure and get back to you.
Hey Mark,
Awesome, thanks a lot for the update! The behavior is actually what we need in order to generate release notes, so it would be great to understand exactly what is happening under the hood.
Thanks again!
Max
From what I’ve gathered, the code in the Octopus codebase that evaluates variables for the release notes differs from the code that evaluates the variables for package information. The code that evaluates variables for package information does not consider scope since it won’t be known until deployment time. Hence, your package isn’t showing any build information on the release page and says that the package will be resolved during deployment.
However, the code that evaluates the variables for the release notes seems to be considering the scope and assuming one of the environments, which is why you’re seeing your build information populated in the notes.
I can’t say why the two evaluations happen differently, but for the most part, we recommend using static package configuration where ever possible and limiting the use of dynamic packages to certain scenarios. This is in line with the Octopus philosophy of building your binaries to produce an artifact that is then promoted throughout your environments so that you know the code being tested in QA is the same code going to Production.
A workaround to this might be to create two separate steps that reference the individual packages and then scope the steps to the desired environments instead.
Another option might be to adjust your build configuration for your release to include the needed files for debugging, allowing you to have a single package that gets promoted through your environments.
I hope this helps. Please feel free to let me know if you have any other questions.
For your first comment, that’s great! I totally understand that these things take time to do and aren’t always realistic to have “right now” be the best time to redo something that already works for you.
Addressing your second comment, after doing a little more testing on my end, it seems that the value that gets picked is whatever value was added last.
In my example here, my configuration variable has three values debug, release, and test. The value that would be replaced in my package id upon evaluation is test since that value is last in the list.
