We have an Octopus project that has steps that call child projects.
Deploying the Octopus project as an Administrator works just fine.
Deploying the Octopus project from our TeamCity CI server fails when it gets to the steps that deploy a release from another project.
This is obviously a permissions issue, but I cannot seem to get it to working.
The TeamCity CI server makes a call as an Octopus user that is a member of a team with both Project lead and Project deployer permissions.
The octopus command being run is:
octo.exe create-release --server http://octopus --apikey SECRET --project E-shot --enableservicemessages --version 7.9.6.99-Jaguar131 --deployto Eshot-Development2 --progress --packageversion 7.9.6.99 --deploymenttimeout 00:35:100:
Thanks for getting in touch. From the symptoms you describe, it appears the problem lies with the permissions and scopes you have assigned to the TeamCity user. The fact an Administrator is able to perform the same deployment is a good indicator here.
For a user to deploy a release of a child project using the Deploy a Release step, that user needs sufficient permissions to deploy the parent project and the child project. In this case you are deploying many child projects from the one parent project, so the user needs permissions to deploy all of those child projects.
In this case the deployment log is showing that the Unable to load release with version 7.9.6.99. This could be due to the release being deleted, or due to the user not being allowed to view the release. Deploying a release requires a lot of permissions, including the ability to View Release.
One way to test is to check that user can deploy all of the child projects in isolation.
The permissions look to be adequate.
I have just tested invoking a release from our CI using an admin user and this also failed with “Unable to load release with version”. Done manually from within Octopus works. Attached are screenshots of the success when a release is triggered via octopus and the failure triggered via the command line.
I think the problem is that the package dependencies of child projects are not being downloaded when called from the command line. Just as an added bit of info, the approach we use is to ensure all packages are assigned the same version for a build.
I’ve just been looking over this to see if I could help out and I noticed that in the release that is working, the screenshot shows the version of E-shot interactions being used is 0.0.10. In the version that fails from the command line it is trying to use the same version as the other packages.
Should it be using the same version or a different version on that step? The UI will always pick latest available if you aren’t explicit, whereas in the command line you’ve explicitly said --packageversion 7.9.6.99. So I think that would explain the different behavior.
You should be able to add --package="Release - Interactions:0.0.10" to explicitly set the version for that one step, if that one needs to be different.
