Clean up docker registries

[qwerty287]

We currently have three registries:

1. Docker Hub
2. Quay (used as backup for main repos)
3. Codeberg (used as backup for plugins)

This should be unified to only have one primary and one backup registry. Best would probably to use Codeberg as backup instead of Quay.

What do you think?

[zc-devs]

Best would probably to use Codeberg as backup instead of Quay

Why?
Also, it is weird to me, that GitHub is used as main platform for Woodpecker developing, but images are not published here at all.

---

The main registry could be used for all images including next-* and pr-*. The others are for releases only.
Honestly, I do not understand projects, which publish on one platform (not applies to Woodpecker). It is just one line of code per registry to copy image from one to another registry.

[qwerty287]

most = not all.

#3530

Was the question about plugins or Woodpecker Server, Agent, CLI?

All of them. Docker Hub is and will stay the primary pretty surely so this is only about the secondary solution which is not consistent currently.

[zc-devs]

In regards #3530: #3995 (comment).

All of them

How can you generalize, if one part is developing on one platform and another is on another?
Also, I'm fine, if GitHub is the main platform for Server, Agent, CLI, but for plugins it would be another platform.

this is only about the secondary solution which is not consistent currently

I think the primary isn't consistent too. If "you" develop on GitHub, then make it primary for containers also, not only for code, issues, discussions, releases and artifacts. The same, if "you" develop on Codeberg (or whatever).

Docker Hub is and will stay the primary pretty surely

I disagree, but it's just my opinion.

[pat-s]

Dockerhub is and will likely stay the Nr. 1 container registry, I agree on this (at least as of today). I don't see why containers should necessarily be published on the platform an app is developed on.

I am also not much of a fan that we publish the plugins both on CB and Dockerhub. But this was already the case when I joined. I would prefer to only use Dockerhub as the registry management on CB and GH is limited and not the primary focus of these platforms.

#3530 is a different discussion.

I see why having at least two registries can be helpful for some scenarios. OTOH, I don't think we should publish to X registries "just because we can", as every assets occupies some resources somewhere and there is no need to copy/store everything X times.

WRT to the initial Q: I am not a fan of using CB as a backup as we would need a repo first. This would cause confusion again WRT to contributing etc. Suggestion: https://artifacthub.io/?

[qwerty287]

I think the reason to have multiple registries was mainly that docker hub introduced some weird limitations for oss projects that would require us to pay (they reverted this change later again).

we would need a repo first

Really? Packages are on user/org scope I think (and can optionally be linked to a repo).

Suggestion: https://artifacthub.io/?

We can just fully switch to quay.io if we don't want to use codeberg.

[zc-devs]

I don't see why containers should necessarily be published on the platform an app is developed on

Because it is convenient for user?

Screenshot 1
Screenshot 2
Screenshot 3

While examples above are on GitHub, the same applies to Gitea/GitLab/(you name it).

docker hub introduced some weird limitations for oss projects that would require us to pay (they reverted this change later again)

I'm happy for OSS projects, but there are still limitations for the users. At least it was a half year ago.

---

Gitea had some permissions problems. Images are linked to a user (as qwerty mentioned). So, if you are public user and publish image for a private repository, then image will be visible. Do not know, if they fixed it somehow.

Docker had (has?) limits for users.

GitHub is not available on IPv6 network.

Suggestion: https://artifacthub.io/?

This feature is experimental and it’s subject to change.

---

go-gitea/gitea#22922
valkey-io/valkey#65

There are much more projects, I'm just lazy to remember and find it.