woodpecker-ci / woodpecker

Woodpecker is a simple, yet powerful CI/CD engine with great extensibility.
https://woodpecker-ci.org
Apache License 2.0
4.07k stars 352 forks source link

Customization options for Containers #1868

Closed schewara closed 1 year ago

schewara commented 1 year ago

Clear and concise description of the problem

Currently the usage of images is very limited, which requires one to implement some workarounds like using custom images/plugins to play along with woodpecker and sometimes existing infrastructure requirements.

Therefore I would like to suggest to add support for the following options to not have to re-invent the weel every time when one wants to integrate a new tool/image which does not match the current limitations.

This list is only my "Top 3" with potentially more options to follow, but these would already cover more then 90% of all my use cases.

Suggested solution

The ability to define specific options for images like:

pipeline:
  test:
    image:
      name: a-container:latest
      entrypoint: [""]
      pull_policy: [always, if-not-present, never]
      labels:
        key: value

or as backend_options

    image: my-container:latest
    backend_options:
      docker:
        prefix: my_prefix_
        entrypoint: [""]
        pull_policy: [always, if-not-present, never]
        labels:
          key: value

Alternative

Currently the only alternative I see, are custom images or plugins tailered to work with woodpecker.

Additional context

Validations

lafriks commented 1 year ago

if we add such docker backend options imho these should be server side configuration options not per pipeline (prefix and labels)

anbraten commented 1 year ago

linking #278

6543 commented 1 year ago

I would say that's are agent backend options ...

6543 commented 1 year ago

or at least some of the proposals

schewara commented 1 year ago

@6543, @lafriks Completely agree with your comments, some options might be better suited for backend options, while others might be a better fit for the pipeline config.

I just wanted to provide an end-user view and would leave it to the experts to decide where the implementation would fit best, as they have a better overview of all the internals.