Event types are poorly named

[not-my-profile]

For reference the event types are:

• push: triggered when a commit is pushed to a branch.
• pull_request: triggered when a pull request is opened or a new commit is pushed to it.
• pull_request_closed: triggered when a pull request is closed or merged.
• tag: triggered when a tag is pushed.
• release: triggered when a release, pre-release or draft is created. (You can apply further filters using evaluate with environment variables.)
• deployment (only available for GitHub): triggered when a deployment is created in the repository.
• cron: triggered when a cron job is executed.
• manual: triggered when a user manually triggers a pipeline.

push and tag

I think the biggest problem with Woodpecker's event naming is that unlike on GitHub/GitLab CI where a push event / pipeline source denotes the git push of a commit or a tag (ref GitHub, ref GitLab) in Woodpecker CI it only refers to pushed commits. Firstly this breaks the expectations of any developer who's used to GitHub/GitLab and secondly it's confusing and inconsistent to have push only refer to commits when tags are also pushed (with git push).

pull_request_closed

Again Woodpecker's behavior is counter-intuitive: a pull_request event is triggered on opening a PR but not on closing a PR. GitHub and GitLab again do the obvious thing instead: triggering it for both (and providing different means of filtering on the subtype).

cron

GitHub and GitLab both call this schedule, so I think it would be nice to align the naming here as well but this is less of an issue.

I think naming is really important in UI design as well as not breaking user expectations so I think Woodpecker should address these problems by deprecating tag and pull_request_closed and instead relying on separate keys for the filtering ... like GitHub/GitLab do.

[lafriks]

I think push will trigger also on tags and can be filtered using ref

[not-my-profile]

No, just as written in the docs that's not the case, see the source for the GitHub forge and the source for the GitLab forge.

[lafriks]

I'm quite sure it was working at least in Drone, might be something has changed

[not-my-profile]

No, this behavior has been this way in Drone, see gitlab.go back then and github/convert.go back then.

[anbraten]

I agree some naming is pretty confusing and inconsistent. One of the biggest issues here is history. The naming was introduced like this in drone <0.8 and changing such fundamental things would require all woodpecker users to adjust their configs or they would simply avoid updating which would be quite sad as well.

[not-my-profile]

I think we could gracefully deprecate them by:

1. making the linter emit warnings for the deprecated events
2. providing some tooling to automatically fix the linting issues (i.e. updgrade the syntax)

My concern is that users that are new to Woodpecker shouldn't have to deal with confusing/inconsistent syntax.

Since you're saying "some naming", are you aware of other naming issues besides the event types?

[anbraten]

making the linter emit warnings for the deprecated events

Would be in general an option. However to be able to do so we would need to find new names for events like push as those can't be changed to be not breaking. Such a transition would need quite some planning and time. Leaving users / whole teams behind as they are not willing to update 1000s of configs at once is still something we need to keep in mind. Especially for none hobby users stability is often way more important than proper naming (don't get me wrong I am a huge fan of clean and straightlined concepts).

Since you're saying "some naming", are you aware of other naming issues besides the event types?

One fundamental difference to some other ci systems is that woodpecker uses filters: when.event => only listen to event ... instead of on / triggers where all events, but the one you specify are ignored.

[not-my-profile]

We could present Woodpecker users with a choice on installation:

• compatibility mode with Drone
• modern behavior without stuff/naming that's only there because it existed in Drone

Ideally we'd still provide tooling to mass-convert repositories from compat mode to the modern behavior.

Supporting two modes of operation does of course pose a challenge to maintenance and documentation however I think it would be worth it to provide new users (who have never used Drone) with a more streamlined experience.

I'd like to use Woodpecker CI in my own projects but I'd really like to avoid having to deal with legacy peculiarities I don't care about.

[qwerty287]

This would introduce too much maintenance efforts. If you are able to handle this, feel free to suggest changes, but I don't think most maintainers care enough about something like this.

it to provide new users (who have never used Drone) with a more streamlined experience.

Might be helpful for new users, but migrations and using new software is always connected with a learning curve. Just trying to do it similar to any other tool (and yes, this includes drone namings) to simplify for new users is nothing I'd go with. Just as @zc-devs said: Use Github/Gitlab/whatever if it's impossible for you to get started with woodpecker schemes.

However, just changing some event names/behaviours is nothing that's too "dangerous" to change I think. There are always people that will dislike a change. Or do you refer to some more changes?

[zc-devs]

this breaks the expectations of any developer who's used to GitHub/GitLab

What's about Drone users?

However, I agree on pull_request_closed.

[not-my-profile]

What about Drone users?

GitHub has over 100 million users and GitLab over 30 million. I coudn't find how many drone users there were/are but I'm pretty sure that it's just a couple thousand. So I think it makes sense to cater to the average developer who's used to GitHub/GitLab.

Besides the big issue with having push only refer to commits is that it's inconsistent with the git terminology ... you git push tags, so this goes against the expectations of any git user even if they haven't used any CI yet.

[anbraten]

Just for some context. pull_request_closed was added that way to avoid conflicts with existing configs: #1451