Hello,
In our development process we do work in feature branches and merge these to develop. A Jenkins build is triggered on a commit to this branch and builds a nuget package with /p:OctoPackAppendToVersion=beta specified. I have configured Octopus to automatically create a release and deploy to UAT when one of these packages is created.
I would like to limit this automatic release creation to only packages with the beta suffix in the package ID. Sometimes we fire off builds for testing purposes that I do not want Octopus to release automatically (they might only go to specific servers, or not be deployed at all). I thought I might be able to accomplish this with the channel package version rules, but I am not sure I am able to do this.
Our versioning is as follows:
Current release: 3.1.49
Current development: 3.1.49-beta.4
Next development: 3.1.49-beta.5
Next hotfix: 3.1.49.1
Next release (fortnightly): 3.1.50
I would like any package pushed with -beta.x to be have a release automatically created and the rest to be ignored.
Okay, as with most things - once I posted here I found exactly what I was looking for. Pre-release tag, not versioning. It was such a simple solution. I have set the channel version rule to match tags with beta.+.
My issue now is getting the pre-release package to trigger an automatic release. As per the documentation, that does not appear to be built in functionality. When I go to manually create a release, all my pre-release packages are selected. Why is no automatic release being created?
Hi Hamish,
Thanks for getting in touch.
To automatically deploy a release once “Automatic release creation” has done its job, you will need to configure your lifecycle to automatically deploy when a release enters the lifecycle phase.
If you have a look at the ‘Lifecycle Phases’ section of the Lifecycle documentation, you will see that when you first add a new environment to a phase, you have the option to “Deploy automatically to this environment as soon as the release enters this phase”.
So for all this to work, you will need to:
- setup a ‘beta’ channel (which you’ve done)
- assign your Automatic Release Creation to use this beta channel (which I assume you’ve done)
- setup a channel version rule to match your beta tag (which you’ve done)
- setup your lifecycle phase to automatically deploy (instructions above)
- make sure your beta channel is set to use this lifecycle (with the automatic deploying phase)
Then when ARC creates the release, the lifecycle phase should auto-deploy for you.
Let me know how you go.
Cheers
Mark
Hi Mark.
Sorry, my issue is the automatic release creation for packages that are tagged beta (ie pre-release packages). In the documentation it states these are ignored by ARC, for good reason. I am trying to override this because I want them to be automatically deployed to our test server. I have read several answers where users have ended up getting their build process to call octo.exe, which I can do too. Is it possible to get Octopus to do ARC for pre-release packages?
My set up is as follows:
Development Lifecycle: automatically deploys to test tagged environments
Development Channel: uses Development Lifecycle, is default channel, Version Rule is all package steps for beta pre-releases.
Trigger: Automatic Release Creation is ticked, the final build package is selected and the channel is Development Channel.
When I do not specify beta in my package name this will automatically deploy. When I do a manual release creation, the pre-release packages are selected as the next version.
There is nothing in my audit log about any failures or errors.
Hi Hamish,
Sorry, I understand now.
Unfortunately this won’t work with Automatic Release Creation.
Currently when using pre-release builds, only the triggering package can be a pre-release. Octopus will then look for the latest stable version of the other packages in the release.
This was a deliberate decision at the time to avoid non-stable versions of packages from affecting a build - it’s particularly useful for teams that have shared packages or use feature branches to organize code. That said, this may be changing soon and there’s a current UserVoice suggestion that you could vote for if you wish to see this implemented (and maybe share your particular use-case if it would help).
As you’ve already noted, a workaround in your case would be to setup a task in Jenkins to use Octo.exe create-release and define all of your package versions for the release, then this should do what you need.
Again, sorry for the bad news, but hopefully you can do this directly from Jenkins using Octo.exe.
Hope this helps.
Cheers
Mark
No need to apologise. in my original post I uses release/deployment interchangeably which is incorrect (I edited it out).
I added an octo.exe step to create a release if it is built from the development branch. This is working nicely and I can already think of a few more channels I could create for hotfixes and alpha (to stop our devs doing DLL drops onto servers to test things).
Thanks.