Templates for manual workflows env vars

[CodeDoctorDE]

Clear and concise description of the problem

When running many manual workflows, it is not very handy to input the keys on every run.

Suggested solution

Create a system for github action like form where you add default values, checkboxes and more. The syntax should be like in github actions:

    inputs:
      next_version:
        default: "0.0.0"
        description: "The next version to be released"
        required: false
      stable:
        default: false
        description: "Is this version stable?"
        type: boolean
        required: false

Maybe adding an extra type of event for tis.

Alternative

No response

Additional context

No response

Validations

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

[zc-devs]

I propose to just display ENV vars from workflow and set default value defined in yaml.

 steps:
   - name: build
     image: golang
     environment:
       - CGO=0
       - GOOS=linux
       - GOARCH=amd64
       - DISABLE_CACHE
     commands:
       - go build
       - go test

[CodeDoctorDE]

Yeah this could be useful. Maybe we should make a opt-in/out for this for internal env vars?

[zc-devs]

make a opt-in/out for this for internal env vars?

Do you mean built-in-environment-variables? I'm afraid, it is not gonna work. Just look, how much vars Server sends to Agent :) (if you on Kubernetes, just describe pod).

[CodeDoctorDE]

No I mean if you define env vars in your workflow you should be able to opt out of this new feature

[smainz]

Just one thing to consider:

We are using the manual pipeline execution to perform builds too, but there are much more environment variables in the steps than need to be set / overriden while performing a build / deployment.

Would a config like

   environement-input: 
     - BUILD_NUMER: <proposed value>
       MATCH_REX: <some regex to validate the input>

be an option?

At the moment we have a seperate step to validate the ENV vars to overcome typos.

[CodeDoctorDE]

That looks good. In the future we could expand this by adding dropdowns with values: ["one", "two", "three"]

[zc-devs]

I'm thinking towards having special syntax for inputs now as both of you have mentioned. I've just looked at one of my pipelines:

# Environments
# SKIP_PACKAGE=true|false - skip package step
# APP_TAG=0.0.1 - override CI_COMMIT_TAG var, application release version

steps:
  set-env:
    image: debian:bookworm-slim
    commands:
      - .cicd/set-env.sh
  package:
    when:
      evaluate: 'SKIP_PACKAGE != "true"'
    image: python:3.12.1-slim-bookworm
    commands:
      - .cicd/package.sh
    secrets:
      - twine_username
      - twine_password

As we can see, I use variables that aren't defined in environment sections. Some of them are not used in pipeline definition even. Furthermore, your variants would make possible enums

dropdowns with values: ["one", "two", "three"]