I have a tenant-only project with ‘Automatic Release Creation’ enabled. The channel that is selected is configured with a lifecycle where the first environment is to be deployed automatically.
There are tenant deployment targets in the auto-deploy environment, and I have tenants which are attached to the project/environment combination.
The ARC works (there is indeed a new release every time I push a package to the given feed), but the release is not automatically deployed. Is this a bug or is there additional configuration I need to look at?
Thanks for getting in touch and I’m glad to see you are getting involved with the 3.4 beta!
This does sound like a bug. I would expect if the first Phase in the Lifecycle has some “automatic” Environments, when a Release is created, Octopus should enqueue Deployments for every Tenant connected to those “automatic” Environments, and if you allow un-tenanted deployments, an un-tenanted deployment should also be enqueued.
Another way I’m thinking about this is that Octopus should automatically click every “Deploy” button in the “automatic” Environment(s) columns on the Project Overview.
Do you think that makes sense for your situation?
Out of interest’s sake, is there a reason you are using “Automatic Release Creation” (ARC) in preference to one of our Build Server extensions to create releases and deploy them?
What you described is exactly the behavior I would expect as well. It looks like this behavior is correct as long as there are no tenants attached to the project. However, as soon as you attach a tenant it seems to stop working.
We did use the TeamCity build server extension for a while, but ARC actually works better for our purposes. To make the extension work properly, we would either have to determine the channel to be released at build start (since it changes depending on the branch committed to), or delete the release generated by the extension when we wanted to make a production release (if we set it to a fixed channel).
We may get there eventually (and I can see that solution being valuable), but for the time being it’s minimal effort to use ARC to deploy our internal development releases, and generate a production release manually. Additionally, we have many solutions which contain multiple elements to be deployed independently, (eg, an API, a client website, a couple Windows Services), but get built at the same time. If we wanted to use the extensions, we would have to configure and maintain each project deployment setting in TeamCity, which adds some overhead.
I just stumbled on this looking through the Diagnostics:
Unable to trigger deployment for project ‘[Project Name]’ release [Release Number] to environment [Environment]: [Project Name] can only be deployed to tenants. Either deploy this release to a tenant, or configure this project to allow un-tenanted deployments. Redirecting to https://octopus.com/docs/tenants/tenant-deployment-faq
Once you have corrected these problems you can try again.
If the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.
If the problem is related to the deployment process you will need to create a new release for the changes to take effect.
So it looks like automatically releasing to tenant-enabled projects is restricted by design. However, I found this also occurs when a tenant-enabled project also allows for untenanted deployments (at least in Beta-002; I have not tested this with RTW). However, I don’t believe this is behavior is documented or intuitive, for the reasons discussed before, and this information is not exposed anywhere except the server logs.
I suppose the question then becomes: is this actually intended behavior?
Thanks for getting back in touch with more information! We should support automatic environments in lifecycle phases more gracefully when tenants are involved.
This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.