Above is a screenshot from your public demo server. How did you configure it to use an image from the feed instead of a package? I’m examining the project setup and I for the life of me don’t know how you got it to go from selecting a package to using a docker feed’s image. On my server, using v 2018.9.15 I don’t seemingly have that option. Would it be possible to have the steps outlined for me so that I could follow them?
Thanks.
Thanks for getting in touch!
It’s hard to determine exactly what is going on here, however I primary suspect is that your docker images have naming that doesn’t conform to SemVer 2.0. We do have a project underway to relax the SemVer requirement for docker feeds (as Docker doesn’t require SemVer) however this will take a while as the reliance on SemVer is baked in quite deeply into Octopus.
If you can confirm your naming convention and let me know if that isn’t the cause of the problem that would be greatly appreciated.
Regards,
Alex
Hi Alex!
You’re correct. Our images are either tagged “latest” (as we want them to be for the master branch), or we assign a ticket #like DEV-12345 as the image tag.
Can you give me an example of how any image SHOULD look, in both name and tag?
Hi Zoren,
Naming strategies can be difficult, as it mostly depends on your deployment process and goals. One possible solution here would to use a naming strategy in concert with channels e.g
[applicationname].1.0.0-dev.12345
[applicationname].1.1.0-production
This lets you define channel rules around the -xxxxx tag so that only images with the -production post fix can go through to the production environment. If desired you could also use Production as a prefix (e.g. Production- [applicationname].1.0.0-dev.12345) so you can tag any release that you want to go through to your production environment.
As I mentioned at the start, this will very much come down to how you want to move packages through your Octopus Lifecycle (or lifecycles) so I can only give general advise. You might also want to look into branches as well, although I’m not 100% it’s relevant in this case.
I hope that helps, if there is anything else I can help with please let me know,
Regards,
Alex
[applicationname].1.0.0-dev.12345
[applicationname].1.1.0-production
So you recommend that the image inside the container repo be named in a similar manner? I’m just trying to make sense of the naming convention.
We just use [applicationname] as our image names.
Sorry, I’m still a bit confused on this subject.
Hi Zoren,
We follow SemVer 2.0, so yes, that is what we recommend (and currently require) for our packages. What it really breaks down to is to following structure
[appname] . [major version] . [minor version] . [patch] - [optional metadata]
The SemVer page has a pretty good description as what they mean by major/minor/patch, but that’s all around application API’s and so doesn’t really apply here. Unfortunately you’ll need to make your own way with versioning numbers for a bit here.
We are looking at allowing arbitrary names for Docker feeds, however for now this code is baked quite deeply into Octopus so it’s going to us some time to remove this requirement.
One thing to watch out for here is that the metadata (anything after the -) doesn’t count as part of package versioning. So if you have AppName.1.0.0-dev12345 and AppName.1.0.0-dev45678 they will evaluate as the same version in Octopus.
Hopefully that helps,
Regards,
Alex
Thank you, Alex. This has been most informative. I’ll work with the team on this and see what we can do about this on my end.
