But no matter what I tried for the package it does not work, e.g.:
# We have such variables at deployment time
#{Octopus.Action[app].Package[app].PackageVersion}
#{Octopus.Action.Package[app].PackageVersion}
#{Octopus.Action.Package[app].Version}
# I tried this variables after reading "Release Notes" guide
#{Octopus.Release[app].Package[app].PackageVersion}
#{Octopus.Release.Package[app].PackageVersion}
#{Octopus.Release.Package[app].Version}
Underneath UI is calling /api/Spaces-1/projects/Projects-1/deploymentprocesses/template?channel=Channels-1 and uses response value NextVersionIncrement
But, because with this call we are not providing selected version, probably backend just can not do it, but who knows, may be I’m wrong or it can be taken to backlog as feature request
Motivation: release names must be unique which harms for setups with many channels, so we can:
use octopus version - but then it is hard to answer which version is deployed
use package version - requires us to manually add some postfix to version name everytime
use combination of package and octopus versions - does not work
The issue that you’re running into is due to the availability of the variables. Because a package is linked to a release during creation, it can’t be used to version the release as a part of that creation mechanism. That sounds really convoluted, but the underlying idea is that since you’re creating a release, THEN selecting the packages, you can’t use that unknown package variable to create the release.
However, there are ways to approach this outside of the Octopus release versioning template - are you creating your release from within a build server using the Octopus integration? One option to consider may be utilizing the build number variables that are usually available in CI tools and manually setting the release number from your CI system. That would allow you to create your unique release identifiers that match explicitly with your package version.
Let me know if that sounds like a workable alternative - I’m interested in hearing more about your use case and trying to help you get what you’re looking for!
I’m not quite sure if I understand it, we are choosing package versions prior release creation on the same page (yes indeed package is linked to release after its being created but from exactly same info we already have on this page)
The same is true about release versioning based on package, e.g. version is being set prior release creation
Also, on that same page API for rule-test is being called to check if selected packages match version rules for a channel and its receive selected packages info
What I was expecting is that API for a template will also receive the same info and will allow us to use its values
As for workaround - we are creating releases from UI manually whenever releasing something (not from CI tools for each build to reduce disk space used by kept releases, doing this from beginning after investigation with octopus team when our instance eat whole space) and still even with such approach I still can not create new release and have both selected package version and revision increment
e.g. from a screenshot it will be like: 2.34.0 for a package version and 24 for revision increment and dev for a channel
Use case here is following:
usually we stick to package based release versioning (allow us to immediately answer the question which exact version is being deployed without digging into release details)
because of multiple channels it forces us to add some postfix manually while creating the release (unwanted experience)
But it requires human to not forget to manually set version, which makes it also useless because loosing main objective with ability to identify released version quickly
BTW, there is a bug and next revision works only if used as fourth number, e.g. if we try 2.34.0-dev-24 it wont work
Thanks for the added information around your use case! Sorry if I was unclear -
The variables prefixed Octopus.Release are release specific. The reason those are unavailable at release creation is because the release itself doesn’t exist yet to have packages attached. The work being done to evaluate package versioning rules is happening on the release creation screen, but there are no variables attached to that data.
Unfortunately, there’s no good combination for being able to automatically parse the version of a package when you also need the channel version included. The closest option is using the Use the version number from an included package option for release versioning in your project. That will allow the release version to appropriately reflect the package version, although you’d still need to add your channel postfix manually, which is unfortunate given your goals.
Sorry there’s not a better way to get this automated to match your use case at the moment - if you’re interested, please post your use case here on our UserVoice site - it will allow others to see your request and hopefully generate more interest around potential use cases for this feature that we can take into consideration as we continue improving the product.
