Rename registries

[qwerty287]

We currently have internal registry support, but this support has some issues in my opinion:

• It is only supported for the docker back end while it looks like being supported by all backends because it's in the main UI.
• They're defined in UI which does not allow to view git history etc. of changes.

My suggestion is to define registry credentials directly in the workflow yamls using backend_options (or any other way):

steps:
  - name: step
    image: registry.com/xyz
    backend_options:
      docker:
        registry:
          username: some-user
          password:
            from_secret: reg_password

[anbraten]

Interesting approach. K8s is / should also use those credentials.

From what I know we have to usages for registries:

• pulling pipeline images from registries
• pushing to registries using plugins (currently not supported, but often expected / requested)

[qwerty287]

K8s is / should also use those credentials.

Yes (I think #3122 should support it), but the local backend will never support it. I think we should only support features on a "global"/"UI" level if all backends support it.

[anbraten]

Ahh I thought they would be already supported

[anbraten]

limitations with current suggestion:

• you would need to define credentials for every step. if we make it a setting for the whole workflow you would still need to set it in every workflow file, maybe time to introduce this special config file (sth like .woopecker-config.yaml) we talked about for crons etc as well
• secrets can have some limiting settings (plugin image names, events) those would just partly make sense for registry secrets I guess

[qwerty287]

One thing that's missing in secrets would be the registryAddress, we could make it possible in the UI to select if a secret should be a "registry-secret" and by show some special hints and the registry address field.

This would add registries back on a "global"/"UI" level again (which I don't like). But yes, we need some filtering.

[anbraten]

This would add registries back on a "global"/"UI" level again (which I don't like). But yes, we need some filtering.

True, missed that the registry-url and user could be set in the new config file #2317. That would be enough.

[qwerty287]

No, because you could steal the secret then by just changing the registry url in config file, then woodpecker will make a request to this registry containing the secret.
We can re-use the image for this though.

[anbraten]

Wouldn't it always use the config from the default branch? For cron or other settings like visibility, ... we could not update them based on configs changed in a PR?

[qwerty287]

Ah yes, in this case, this would be fine. Forgot about this

[6543]

We have no other way to pull images from private registrys.

How would this work with secrets?

[qwerty287]

I think we gave examples already. Take a look at my first suggestion in the discussion description, I suggested using backend_options.
@anbraten noted correctly that this would mean you have to set the registry author for every single step, so the suggestion was to implement this together with #2317.

[6543]

well I still think this will just make it more complex and the current sollution works just fine.

what are the current downsides of the impl. ?!?
i se only pro:

• can never be leaked into ci
• easy to setup & adopt
• solve the chicken/egg problem in an elegant way

[qwerty287]

what are the current downsides of the impl. ?!?

My main issue has something to do with the original idea/focus behind Woodpecker (or probably even drone at this point).

They built a "container-first" CI system which kind of means "docker"-first. Thus, there is a lot of code that's completely specific to Docker and not adoptable to other backends we introduced since then (just an example: #3156).
To not do this, we introduced backend_options to be able to use backend-specific options without having to add them to the core.

(If you want to respond before reading the whole comment, please finish reading first ;) )

Now, about the current situation of registries: They are a left-over of times when only Docker was supported. local and kubernetes do not support it. Thus, it should definitely not be added to Woodpecker's core, but rather to backend_options.

can never be leaked into ci

We can add specific restrictions to prevent this.

easy to setup & adopt

Secrets and backend_options are also very easy to use.

solve the chicken/egg problem in an elegant way

Which chicken-egg-problem? I don't see any. We don't need to fetch the image from the registry to read secrets from our db.

---

That's only the current situation.
However, it looks like it's changing - for Kubernetes, #3122 is in progress, and for local, the issue #3217 is about this. Both will support registries in an appropriate way for the backends.

So, with this, I think I might need to revisit my opinion about this, and if we support these features for the backends, we can keep registries from my side.

With one exceptions: the name. It should not be called "registries" anymore because that's a docker-specific term, but rather "Authentication" or something else that's generic.