Any plan to support tag_push_event of gitlab?

[depay]

As we wanna trigger some action by gitlab tag event, e.g. building&pushing docker image, tag_push_event supporting is required.

i've submit a PR in Bugagazavr/go-gitlab-client to support tag_push_event by go-gitlab-client. kzaitsev/go-gitlab-client#11

[bradrydzewski]

Yes, I started laying the groundwork in the next release for such a feature. I've added the ability to enable a repository to build tags (similar to pull requests and pushes):
https://github.com/drone/drone/blob/0.4-database/pkg/types/repo.go#L60:L64

I've also updated the git plugin to fetch refs, which enables tags:
https://github.com/drone-plugins/drone-git/blob/master/main.go#L139:L146

I've also removed database restrictions that exist in 0.3 (current stable) that prevent this feature, specifically the unique indexes.

In addition to the above changes, we'll need the ability to restrict publish and deploy steps to tags. We'll need to alter the Condition structure which exposes conditional logic in the yaml:
https://github.com/drone-plugins/drone-git/blob/master/main.go#L139:L146

Second, each plugin (GitHub, Bitbucket, etc) needs the ability to enable tag hooks. I believe this is already the case with GitHub, but we'll need to do the same with other systems.

Third, each plugin needs to be able to correctly parse the hooks and convert to a build object. This will need to be implemented for each plugin as well.

Last, we'll need to add a toggle to the user interface to enable / disable executing builds for tags. I believe it should be off by default, and something that can be manually enabled in the repository settings screen.

This isn't an immediate priority for me since I'm still trying to get a working version of 0.4 release before adding new features, but those are the required steps if anyone wants to jump in and start enabling this feature :)

[depay]

thanks @bradrydzewski . i'll do something on it, as it seems immediate for me lol.

[bradrydzewski]

help is much appreciated :) please know, however, that 0.4-database is not yet functional and there is quite a bit more work required to push a beta release

[bradrydzewski]

dupe of #468

[os12]

Hi Brad, how far did #1130 go?

The use case I have in mind may be a little simpler than a custom "tag recipe":

1. [Human] creates an annotated tag
2. [Human] pushes the tag to GitHub
3. [Drone] starts a normal build
   1. detect that the build is related to a tag
   2. perform a normal build
   3. do some extra steps when tagging (eg: publish the artifacts)

Is this possible today?

Thanks!

[bradrydzewski]

@os12 yes, in your repository settings in drone enable tags (via the toggle). Then in your .drone.yml file you can mark specific publish or deployment tasks for tags. See http:https://readme.drone.io/usage/deploy/#conditions:0814af543608f4fd171b2e9cf43d9917

[os12]

Thanks, Brad! Could you clarify the following please:

1. Did the patch make it into 0.4.0?
2. It it possible to invoke a script from the publish: section?
   • the vm/container is already configured with Google Cloud Storage access and has the official tools
   • is there a "shell" plugin?

[bradrydzewski]

Did the patch make it into 0.4.0?

Yes

It it possible to invoke a script from the publish: section?

No, this is not possible without a custom plugin

Instead I would recommend using the new multiple build step feature. You could create multiple build steps, and make one of the steps conditional to only execute for tags. Furthermore, steps don't execute if preceding steps fail.

You can read more about it here:
http:https://readme.drone.io/usage/build_test/#conditions:fb92aa3346185c57f15afda861d465a3

Even though the step is in the build section, it will behave almost identically to a step in the publish or deploy section when proper conditions are applied.

is there a "shell" plugin?

No, there is no official shell plugin.

This is because plugins run in their own isolated containers and as a result, there is no way for us to provide a generic shell image that would meet the requirements of most teams (OS, installed software, etc).

You can always create and white-list your own shell plugin. This is an example of someone's custom shell plugin: https://github.com/crhym3/drone-plugin-bash