drone-docker
drone-docker copied to clipboard
drone-plugins
add support to control which tags auto_tag creates
We release new versions of multiple minor version images in some builds which means that the {image}:{major} tag randomly switches depending on the last build of any 1.x release series .
So either auto_tag can transform into in addition of being an boolean option also support a list of version tags or it's own option:
auto_tag_versions: ['major', 'minor', 'patch']
auto_tag is meant to be opinionated and simple. Either you use it as-is or you do not use it at all. There are too many ways to customize tags and if we go down this path, we have to consider other requests to customize auto_tag such as adding branch, commit sha, etc. I therefore prefer to keep auto_tag simple.
Hover, I do think a good compromise would be to allow custom tag logic via an external starlark script that you checkin to your repository. Thoughts @tboerger ?
We also have a related problem with several repositories where we release multiple services from one repo using tag prefixes.
Auto tag cannot handle it tags like cmd/foobar/1.4.3 or cmd/foobar/v1.4.3.
The .drone.yml section looks something like this.
- name: docker/foobar
image: plugins/docker
settings:
repo: dreg.example.com/project/foobar
dockerfile: contrib/drone/Dockerfile.foobar
when:
ref:
- refs/tags/cmd/foobar/**
I could also write a separate drone plugin that can create .tags files based on various rules.. Right now each project has some code to handle these things individually but scripting support build into this image would be much more convenient than any other solution.
I could maybe have a go at it experimenting some to get a POC.. I have been wanting to try use *lark for something but have not had a real project.. I'd guess that we would add in builtins for semver parsing (in go) so there are a reasonable set of utility to work with. Do any other drone plugin have lark scripting now?
I'm not a big fan of changing the auto tag behavior, as brad said it's pretty simple intentionally.
Every other special case can make use of the tags file.
From my experience your use case seem to be more of a corner case.
supporting multiple minor releases of software is certainly not unusual. I am not talking about changing the behavior, just extending it. But sure, I can make my own version parsing plugin.
Btw. my second example more or less maps to how go modules works for multi module repositories as well . From my experience it's the go to solution for when you want a lot of projects in one synchronized code base with git.
My dilemma is a bit different but it may still worth discussing it here because as far as I can tell, the auto_tag feature silently ignores semver parsing failure and returns latest instead.
I'm not a big fan of changing the auto tag behavior, as brad said it's pretty simple intentionally.
I acknowledged that you are not accepting pull request to change the auto_tag behavior but would you @tboerger & @bradrydzewski be so kind to clarify why the current implementation behaves like this?
Of course, it causes problems to us because our staging environment depends on (ie. pulls) the latest images so whenever a not semver tag hits the repository, auto_tag eventually moves the latest tag to another arbitrary image in the repository.
IMHO it would be better to make the build fail or use the provided tag as is.
clarify why the current implementation behaves like this?
no reason. I probably did not consider this implications of this edge case when I wrote the code.
IMHO it would be better to make the build fail or use the provided tag as is.
this seems reasonable to me. I think using the tag as-is if semver fails would seem to make sense.