Ensure that drone tags 1.16.x and 1.16 on push to v1.16.x tag

[zeripath]

We need pushes to v1.16.9 to create tags to 1.16.9 and 1.16 but not 1 or latest.

We have previously adjusted the manifest to remove the latest tag, and have removed
auto_tags so that 1 does not get tagged but in doing so we also stopped 1.16 being
tagged. So here we just state the that we tag x.yy in addition to x.yyz*.

Signed-off-by: Andrew Thornton art27@cantab.net

[richmahn]

Does a release of the release/v1.17 branch make a 1 tag though? If so, then it would somehow have to know if there are tags greater in semver number than itself, such as v1.17.0-rc > v1.16.9 (when releasing v1.16.9) then don't create tag 1. Or is the 1 tag done away with all together?

[zeripath]

Does a release of the release/v1.17 branch make a 1 tag though?

What do you mean release of release/v1.17 branch?

If you mean a tag from the v1.17 branch, yes it will. The .drone.yml file there has:

gitea/.drone.yml

Line 905 in 317c565

auto_tag: true

Which uses the drone-docker plugin to create the following tags: (see https://github.com/drone-plugins/drone-docker/blob/a842dfe5571a7f204e00d138458b67d6153de3b4/tags.go#L42-L72)

	return []string{
		fmt.Sprintf("%0*d", len(dotParts[0]), version.Major),
		fmt.Sprintf("%0*d.%0*d", len(dotParts[0]), version.Major, len(dotParts[1]), version.Minor),
		fmt.Sprintf("%0*d.%0*d.%0*d", len(dotParts[0]), version.Major, len(dotParts[1]), version.Minor, len(dotParts[2]), version.Patch),
	}, nil

If so, then it would somehow have to know if there are tags greater in semver number than itself, such as v1.17.0-rc > v1.16.9 (when releasing v1.16.9) then don't create tag 1. Or is the 1 tag done away with all together?

This PR is only on the release/v1.16 branch. It makes no change to the v1.17 branch.

Tags from the release/v1.16 will create tags on docker for 1.16 and 1.16.x and will not touch latest or 1