When we create project deployment steps for those requiring some package to deploy we identify it by Package Feed and Package Id. So far so good. Library also shows us available packages by Package Id. When we build packages with Octo or TeamCity plugin we also encode Package Id and version in ZIP file name. It makes sense to me so far.Then it comes to Release creation and to my surprise and confusion we suddenly MUST identify packages not by their Id, but by the name of the project step which uses it!
On TeamCity Create Release runner page we have tiny space for “additional command line arguments” and we have to squeeze there long list of package versions which consists of items like that: --package “Deploy FrontEnd:%dep.FrontEnd.build.number%%octoChannelSuffix%”
I seriously need help understanding the motivation and logic of this design, because
- Deployment step name supposed to be readable and give a hint what the step is doing, so more often than not it contains spaces, which makes it harder to use as identifier;
- The fact that mere giving deployment step slightly better name may and will cause Release creation breakage in TeamCity is mind boiling.
- What if we don’t have one to one relationship between build steps and packages - how this supposed to work?
I see many huge drawbacks for this way of referencing packages and badly need help understanding why referencing packages by Id uniformly, as deployment steps do, was not good for the purpose.
Thank you beforehand!
Konstantin
Hi Konstantin,
Have you had a chance to read the docs on creating a release through octo.exe? This is what the TeamCity plugin calls under the hood so it needs to abide by the same conventions.
As noted in the documentation, when there are multiple steps with different packages, we need some way of telling which version you want for each package step in the release. There should be a one to one mapping between a package and a step since you can only select a single package for a step and (as you can see in the Create a Release page in the portal) you need to specify each package for each step independently. If you had the same package specified for multiple steps (which some people do) we need some way to tell which version of the package is required for each of the steps. Through the command line the step name seems like the most logical identifier for a step. If you have a single package step though, then you don’t need to specify the step name.
I hope this helps to clarify somewhat why octo.exe (and by extension, the plugins) work the way they do. We are always keen to hear our users feedback so let us know what we can do to help make this less confusing.
Cheers,
Rob
Thank you, Rob! Indeed I can use --packageversion option to set the common version for the MOST packages to be used, but there is one among them which we always want latest. How to express that on the command line?
When I was specifying the version for each package individually it was clumsy, but I could just skip the one and latest was assumed. Now when I use --packageversion command line is dramatically shorter, but the same version is assumed for that special package too, which is wrong. Is there a way to specify “latest” (or version range) for particular package?
Hi Konstantine,
As noted in the octo.exe command line help the --packageversion command provides:
Default version number of all packages to use for this release.
Override per-package using --package.
Unfortunately at the moment there is no “latest” you can set for a specific package so you will need to provide one explicitly using the --package argument. Feel free to take a look through the source code here and issue a PR if you feel that you could add some suggestions to its functionality. If you are creating this through an automated Team City process is this a blocker for your deployments or just wanting to shorten the command?
Cheers,
Rob
It is really just to shorten the command. Before your answer I was not aware that I can specify default package version and instead provided explicit version for all packages on the command line which become humongous. Now I just shortened some dep. TeamCity references and the command line become acceptable. I’m going to leave it like that - it is good enough.
Thank you!