I am trying to create Octopus Release from TeamCity. I want to exclude some steps in deployment process and hence I want Octopus not to check if corresponding packages exist in feed. Also these steps are scoped in Octopus to run only in specific environments in which packages exist in feed.
I tried to exclude this step when I call octo.exe from TeamCity with --skip=“stepname” parameter. But no luck. The only way to skip a package check for deployment step is to disable it. Which is obviously not an option.
In this case, create-release wraps together two operations under the covers. First, it creates a release, then it creates a deployment, in much the same order as you’ll have used in the UI.
Because of the order that happens in, it doesn’t know what steps are being skipped at the time the release is created, so Octopus demands a version for all the packages. There isn’t really a way around this - a release needs a version for every package included in that release, even if that package isn’t subsequently deployed
The fix is to provide a valid version of the package - either explicitly or by allowing Octopus to resolve latest automatically - even if it’s not being included in the subsequent Deployment.
Hi Jason,
thank you for you reply! So there is no way to skip this package check at moment of creating release? Even if this package is in deployment step that will be skipped later?
As well as I understand as workaround I can put dummy this package in feed and explicitly indicate it when I create release?
Just filling in for Jason as he’s away today. As he mentioned, when Octopus creates a release it checks to make sure it is valid for all possible scenarios. It doesn’t know and can’t assume that you are going to skip that step when you do a specific deployment.
Creating a dummy package could possibly work around it, but isn’t something I’d really recommend. Are you able to elaborate on the nature of why this particular build isn’t going to run that step? E.g. I’ve seen hotfix scenarios where the deployment process is a bit different to the standard deployment.
If you have a scenario like that, maybe channels might be able to help. Each channel can have a different lifecycle, if you need that, but you can also scope steps to particular channels. When you create a release, you specify the channel it is for (it goes to the default channel if you don’t specify a channel) and the package validation would be based on the steps for that channel. Note that in TeamCity our extension doesn’t currently show Channel as a specific field you can enter, you’ll have to provide --channel= through the Additional command line arguments value.
Thank you Shannon! I will experiment with channels and let you know if it works for me. I just wonder why Octopus can use channel based package validation and not environment based.
