Need both environment and settings for plugin appleboy/dron-ssh, but this is deprecated

[smainz]

Component

server

Describe the bug

I am using this drone plugin: https://github.com/appleboy/drone-ssh

And I need additional env vars set in my script (and the optional env var for deployment $TAG will override the constant dev)

  - name: Deploy to Server
    image: appleboy/drone-ssh
    environment:
      TAG: ${TAG=dev}
    settings:
      proxy_host: jumphost.xxx.xxxxxx.xx
      proxy_username:
        from_secret: SSH_USER
      proxy_key:
        from_secret: SSH_KEY
      host: "10.1.0.5"
      username:
        from_secret: SSH_USER
      key:
        from_secret: SSH_KEY
      envs:
        - TAG
      script:
        - cd /srv/docker.nbr
        - echo "TAG=$${TAG}" > .env
        - docker-compose pull
        - docker-compose down
        - docker-compose up -d

How is this supposed in the futire as I get the linter warning: Should not configure both environment and settings

The docs of this plugin explicitly state this kind of usage. Is there differnet woodpecker plugin for the same use?

Steps to reproduce

Should be obvious

Expected behavior

No response

System Info

Woodpecker 2.7.2 from docker image

Additional context

No response

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]

[qwerty287]

You should tell the plugin author that everything should be configured with settings.

However, it's not directly deprecated, you can just use it if it works for you and it should continue working. You just don't have access to some plugin-specific filters like secret filtering.

[pat-s]

It is a Drone plugin, it won't necessarily follow WP conventions. I think as this point in time, many old drone plugins will stop to work with WP due to the recent secrets:/environment: changes.

We should highlight that most Drone plugins are not compatible anymore.

[smainz]

If this is the informed decision to give up compatibility to drone plugins this should be stated on the website.

At the moment the plugins doc page (https://woodpecker-ci.org/docs/usage/plugins/overview) points to this impressive list: https://plugins.drone.io

For this particular plugin, I need environment variable string operations on an arbitrary list of vars.

envs:
  - TAG

passes the plugins env var TAG to the remote host before executing the script.
The plugins env var TAG is evaluated in the agent based on a variable passed to a deplyoment event

So in the end I will need something like:

- name: Deploy to Server
    image: <modified appleboy/drone-ssh plugin>
    settings:
      ...
      username:
        from_secret: SSH_USER
      key:
        from_secret: SSH_KEY
      envs:
        - TAG=${TAG=dev}
        - OTHER_VAR:
          from_secret: SOME_SECRET        
      script:
        - <commands executed on the remot host, using ${TAG} and ${OTHER_VAR}>

Can the parser handle this syntax and what would the plugin get?

[pat-s]

If this is the informed decision to give up compatibility to drone plugins this should be stated on the website.

Agreed, this is currently not reflected at all, I guess.

So in the end I will need something like:

Correct. Simple strings and maps work without issues, however lists don't work OOB with the new from_secret syntax. Plugin maintainers needs to make adjustments. See here for an inspiration how this could be done.

I am not sure which version you're on but if you're not yet running next, you can stick with 2.7 and maintain compatibility until plugins have caught up or ask/push for a WP native plugin.

[smainz]

I am on 2.7.2, so this is not a problem right now, but we still use a lot of drone plugins and I need to plan ahead.
Probably I can fork the plugin and apply the changes myself.

But it will be hard to get the "This is a plugin for drone and woodpecker" out of the internet. Personally I would not care to maintain two similair plugins if I only use one or the other build system.

[zc-devs]

I think as this point in time, many old drone plugins will stop to work with WP due to the recent secrets:/environment: changes. We should highlight that most Drone plugins are not compatible anymore.

you can stick with 2.7 and maintain compatibility until plugins have caught up or ask/push for a WP native plugin

Hooray! I'm in!

#3846 (comment)

We keep the drone vars to be compatible to drone plugins

#4098 (comment)

But we do document that drone plugins can be used just natively

[pat-s]

But it will be hard to get the "This is a plugin for drone and woodpecker" out of the internet. Personally I would not care to maintain two similair plugins if I only use one or the other build system.

I fully understand your point. I guess Drone compatibility was great "until it lasted" - overall Woodpecker is a hard-fork and compatibility won't last forever.
Drone itself is pretty much dead, including the plugins, so maintainers and users both have the choice to fully switch or stick with old versions / the old side.
That being said, plugins without lists in settings that often require secrets inputs are not affected and will just continue to be compatible.

NB: this breaking change wasn't forced to enforce this break, everyone would like to stay compatible. Also, I didn't push for this change to happen. I am only moderating.

Personally I would not care to maintain two similair plugins if I only use one or the other build system.

Sure, nobody would. If you really attempt a fork and the initial maintainer is not interested in a port, you are welcome to host it within https://codeberg.org/woodpecker-plugins if you want. Not a requirement, of course.

---

We keep the drone vars to be compatible to drone plugins

But we do document that drone plugins can be used just natively

Most are still compatible. And the breaking change isn't even in effect yet. Everyone is welcome to contribute to the docs. Rephrasing the docs and stating that some plugins might not be compatible anymore is a welcome action.
So far, nobody was actively aware of this and the offset in the docs. Everyone is just trying to help, things will go missing, get overlooked, will require fixing. That's how FOSS development works 🙃️

[zc-devs]

The problem is not in docs or FOSS or whatever.
We are talking about 3.0 (next), my proposal was for mentioned branch.

I was told twice by two of maintainers, that there is the compatibility. Last time it was 9 of September.
Now, 22 of November, you (maintainer) tell us, that well... you know... that... tldr there is no compatibility.

But we do document that drone plugins can be used just natively

So, decide whether you have compatibility or not. And then we can fix the docs, plugins page, tackle PRs accordingly. Here is the FOSS part:

@woodpecker-ci/maintainers please vote on this post: 👍 maintain compatibility with Drone plugins and advertise it 👎 do not

[pat-s]

Nobody can follow all conversations and I can't speak for others. All people of the "maintainers" team speak mostly for themselves first and one shouldn't take all statements as a general opinion of the entire group.

Reality is that the breaking change forcing the use of from_secret: broke Drone compatibility partially, whether or not that was indented. I don't know if full Drone compatibility did exist before this.

And I also can't speak in the name of others, yet I guess that "Drone compatibility" is not necessarily inferring full compatibility as WP is not a soft-fork of Drone (and never indented to be).

I only tried to communicate here what is the current state. I did not make any of the decisions leading to this change and hence won't take any responsibility for them.

[smainz]

For me as a user the drone, compatibility is not an issue if we are talking about the syntax of the pipelines.
If plugins become incompatible, I need some time to migrate, which I am willing to do.

If the projects decision is to give up (partially or completely) the drone compatibility this is ok for me if this is communicated in advance on the website so everyone can prepare. Maybe the original drone plugin authors will contribute if they know what is going on.

Sometimes a clear cut is better than half baked compatibility. At least it gives more room for improvement.

[zc-devs]

Drone itself is pretty much dead

Doesn't seem so: 1, 2. BTW, they promise compatibility with Drone plugins in Gitness.

[pat-s]

Will Gitness maintain API compatibility with Drone?
We will investigate creating a compatibility layer.

Besides, Drone had 10 commits in a year.

Also: https://github.com/harness/harness#where-is-drone

The goal is for Harness to eventually be at full parity with Drone in terms of pipeline capabilities, allowing users to seamlessly migrate from Drone to Harness.

-> Drone is dead, whatever "Gitness" will be in the end. Users need to decide at some point whether they want to go with Gitness or WP.

[zc-devs]

Drone is dead

Linux has won, Windows is dead. I doubt they will cancel their contracts and leave customers without support.

Users need to decide at some point whether they want to go with Gitness or WP
Gitness is the next major version of Drone

Let me rephrase: users need to decide at some point whether they want to go with Woodpecker 1 or 2 or 3. Fair enough.
Or even funny: as Woodpecker v3 is coming and v2 will be dead, users need to decide whether they want to go with Woodpecker or Gitness.
At some point we'll all be dead, but now we're alive.

Drone had 10 commits in a year

Woodpecker had 0 commits in a year for v1. Thanks God 6543 we have backports now. How many commits did Woodpecker have in 2.7 since main became next 3.0? Do not count 2.8 as it has not been released yet. And if count, it would be around +4.

---

OK, I'll do the rest in copy pasting.

Will Drone pipelines work with Gitness? Yes
Will Drone plugins work with Gitness? Yes
Will Drone extensions work with Gitness? Yes
Will upgrading to Gitness require a complex migration? No. Because Gitness is the next major version of Drone, upgrading to Gitness should be no different than upgrading to a newer version of Drone.
Will I be forced to use Gitness for code hosting? No
When should I upgrade from Drone to Gitness? We will recommend upgrading to Gitness once a stable release is published. The requirement for publishing a stable release is full backward compatibility with Drone 2.x and a seamless upgrade experience.

Looks promising. Why would users choose Woodpecker over Gitness at all (migrating from Drone v2)?