search

startersclan / docker-steamcmd

Dockerized steamcmd with dependencies for building Source / Goldsource dedicated server images. 🐳
Apache License 2.0
3 stars 2 forks source link

docker hub repo should be `startersclan/docker-steamcmd` #9

Closed leojonathanoh closed 2 years ago

leojonathanoh commented 2 years ago

Current

startersclan/steamcmd

Expectation

startersclan/docker-steamcmd

Discussion

See https://github.com/startersclan/docker-steamcmd/pull/8#issuecomment-950651836

joeltimothyoh commented 2 years ago

Again this goes against docker image naming conventions. It isn’t as though the game images are or would be named the same way.

joeltimothyoh commented 2 years ago

Closing.

leojonathanoh commented 2 years ago

Again this goes against docker image naming conventions.

Remember we discussed that any difference between a github repo and a docker hub rep makes the ci "specific" and not reusable. thats why we agreed that all docker-* repos to be uniform across git repos and docker registry repos. Because github and docker hub by default only allow a single level namespace, i.e. <namespace>/<project_name>.

The only reason for needing docker-* supplementary repos (i.e. docker-<binary>) is because the upstream <binary> repo did not build a docker image. So to differentiate any upstream repo from the docker-<binary> supplementary repos, one needs to namespace the supplementary repo with a docker- prefix, so that it becomes mynamespace/docker-<binary> (e.g. startersclan/docker-steamcmd), so that it reserves the actual namespace/<binary> (e.g. startersclan/steamcmd) for the fork of the upstream repo project.

leojonathanoh commented 2 years ago

It isn’t as though the game images are or would be named the same way.

This is not a good argument. The docker-sourceservers repo is an exception from all other docker-<binary> supplementary repos, because sourceservers is not a binary. Instead, docker-sourceservers is a centralized way (thinking about it, it seems wrong now) of managing multiple steamcmd game docker images builds (e.g. hlds/czero, srcds/csgo games).

But even if the game images would be "named the same way" as all other docker-<binary> supplementary repositories, the game URIs would have been namespaced under docker-sourceservers/<binary>:

which i believe we agree doesn't seem correct because consumers don't think of a gameserver as a tool called hlds_linux or srcds_linux.

So knowing that docker-sourceservers is a repo that doesn't subscribe to the docker-<binary> convention, not using the docker-<binary> convention to name the steamcmd game docker images (e.g. hlds/czero srcds/csgo games) is not a valid argument for not adopting docker-<binary> convention for this repo i.e. startersclan/docker-steamcmd. Because steamcmd is a valid binary, this repo is considered a docker-<binary> supplementary repo. See definition in my earlier reply https://github.com/startersclan/docker-steamcmd/issues/9#issuecomment-955197632.

leojonathanoh commented 2 years ago

i am reopening this issue because this issue is worth discussing.

joeltimothyoh commented 2 years ago

Image naming conventions go by what’s most intuitive to users - the namespace, followed by the abstract name of the application, not the binary name. And definitely not with docker-* in the name as though it isn’t already so that the images are based on docker. The changes you’ve been introducing the past couple months are veering off to becoming your own instead of what’s generally agreed upon by the community. Apologies but I’ll have to turn this one down as I can find no fault in the present (and original) names of images produced by this repository.

leojonathanoh commented 2 years ago

I did some research.

Some examples of supplemental repos and their docker repos:

These repos all seem to adopt "intuitivity" (i.e. <namespace>/<binary>) just like you said. intuitivity is a big plus for users, but management of namespacing is another issue for the developer.

However, arguably, users of an image might not just be laymen, but developers as well, and conventional namespacing (i.e. standardization) can actually make things more intuitive for developers. Having no difference in repo names between github and dockerhub greatly increases intuitivity and familiarity, and creates a nice namespacing that preserves the <namespace>/<binary> for the fork of the actual <binary> tool, as mentioned in https://github.com/startersclan/docker-steamcmd/issues/9#issuecomment-955197648.

Also, most of the examples i gave above already have "repo-specific" changes. It will be "nice and intuitive" to have <namespace>/<binary> for users, but it weighs down on the developer. Once there are multiple repos, the burden of managing all of them can be so off-putting the project simply dies. What im suggesting is to keep repos as modular, standardized as possible for scalability and manageability.

in no way, am i insisting that my ideas should be implemented, i'm throwing out my best ideas in order to improve streamlining ci and standardization. one person might be able to maintain a one repo, or a few repos, but one person with standardization can maintain thousands of repos. that's my take at least.