Introduce step type

[zc-devs]

Consider to use separate step type for general steps and plugins.
It would prevent cases when plugin step magically becomes general if you add some keywords.

https://developer.harness.io/docs/continuous-integration/use-ci/use-drone-plugins/run-a-drone-plugin-in-ci
https://developer.harness.io/docs/continuous-integration/use-ci/run-step-settings

[qwerty287]

Not sure if I get your whole point, but this would only allow to get warnings in the linter, right?

In this case, I'm not quite sure about this. Is your main problem that we introduced some breaking changes or do you mean e.g. adding commands results in a non-plugin?

[anbraten]

We could make the linter more strict about mixing plugins and command steps. I would like to avoid some extra key like (type: plugin) to specify that and rather stick to a clear rule on the existing properties.

For json schema detects this correctly already:

"anyOf": [
        {
          "$ref": "#/definitions/commands_step"
        },
        {
          "$ref": "#/definitions/plugin_step"
        }
      ]

and avoids mixing plugin properties with those from commands, right?

In general the rule is no entrypoint & commands are plugin-steps. Plugin steps can provide settings.

We could update the docs to be clear on this.

[zc-devs]

In general the rule is no entrypoint & commands are plugin-steps.

Not exactly, #4375 (comment).

Plugin steps can provide settings.

steps:
  test:
    image: alpine

Plugin or not? Or local binary?

avoids mixing plugin properties with those from commands, right?

Seems, yes, but in the end I can only see the issues and questions, cause of this magic.

I would like to avoid some extra key

What's about steps for local backend? #3997 (comment)

Besides, there #3411 (comment) is not the case, seems.

[zc-devs]

this would only allow to get warnings in the linter

Errors. Strict schema. Like orange is orange, potato is potato.

we introduced some breaking changes or do you mean e.g. adding commands results in a non-plugin

All of them, I think. This not a plugin anymore magic. #4027

Cannot find issue where I proposed to use settings as plugins distinguisher. Like if image + settings => plugin, if only image => general step. And 6543 replied, that won't work, cause plugins could be without settings.

#3997
So, we have 3 different types of steps:

1. Shell for local backend
2. Container general
3. Container plugin

I want there be strict schema for each type.

Is that local step? Speak Friend and Enter Set type:local and you can use envs, secrets, commands, shell, but not image and entrypoint.
Is that container general step? Set type:general and use envs, secrets, commands, entrypoint, image.
Is that plugin step? Set type:plugin and use image and settings only.
⬆️ for examples, not strict wording.

[zc-devs]

Shell for local backend
How is this a different usecase? It's kind of also a general container.

#3997. It's not a container and there should not be an image (and entrypoint ideally). Drone syntax.

[qwerty287]

You mean there should be no entrypoint? Or only entrypoint?

[zc-devs]

First, there should not be image and ideally should not be entrypoint, because they are words from containers world. In local backend we have shell and commands.
Theoretically, you could argue that there could be a case when you want to run only one program/process with some arguments directly without a shell, but is that case really needs to be considered? Is there the people, who want to use it in that way?
And even if yes, I would introduce another two words like program, args in the separate local backend step schema: (shell + commands) or (program + args).

[qwerty287]

In general, I agree to you, but this will make it extremely complex.

---

This discussion actually goes into a direction directly connected to woodpecker's core principles.
Currently, woodpecker is mainly focused on containers. See e.g. https://woodpecker-ci.org/docs/intro#do-you-know-containers The local backend is something really basic and while it's nice to have, it's just completely different from what the other backends (not only docker and kubernetes, but also possible ones added in the future like podman) do because it's not container-focused.
We should ask us whether we want to focus on that core principle or if we want to open that. So the main question is kinda: Do we want to provide a good (aka the best possible) container based system or have a much more complex system?

I actually thought about starting the discussion about this point some time already, but didn't do it yet... So maybe it's a good point here ;) (but, if we start to discuss this, we should move that into it's own discussion).

[zc-devs]

If you wanna get rid of Local backend, it would be another story / case. Do it first and then we will talk about needless of type and my proposals.
Until then let me treat Local backend as first-class citizen of Woodpecker. For now, It is not even experimental. So, please, think about how to make possible for different backends to live together in not so ugly way, how it is now. The links to how it could be implemented / implemented in other systems have been given.
Looking forward for widely discussed and accepted solution.

[zc-devs]

Actually, for local backend would be better to move type to root, because

1. WP schedules workflows and you cannot use local step with container step in the same workflow
2. As all steps in a workflow would be type of local, it is not so convenient to copy paste the same line in each step.

See again Drone syntax for local backend workflows.

---

Edit:
Or how about to make root type as default type for all steps within workflow?

1. If root type = local, then you cannot define other type in steps
2. If root type = container-shell or container-plugin, then you can define/override only container-shell or container-plugin types on step level.

[6543]

the WebUI could aslo indicate that a step is counted as plugin ... we now have that information

woodpecker/web/src/lib/api/types/pipeline.ts

Line 128 in 09ad418

type?: StepType;

woodpecker/web/src/lib/api/types/pipeline.ts

Lines 145 to 151 in 09ad418

	export enum StepType {
	Clone = 'clone',
	Service = 'service',
	Plugin = 'plugin',
	Commands = 'commands',
	Cache = 'cache',
	}

[zc-devs]

Actually, I really like this approach. User is aware of what is going on, the warnings and docs will do the rest. This is for plugins vs commands.
The open question is Local backend's steps.

[6543]

There are no local backend steps ... but you could say workflows targetin different backends. So the webUI can indicate that if, e.g. labels.backend: local exist ...