Add alternative Dockerfiles and a basic CI

[dubvulture]

Updated Dockerfiles using official steamcmd docker images (ubuntu-20). Provides three different versions:

1. vanilla (wine-stable 5.y.z from ubuntu 20.04 repositories)
2. wine6 (wine-stable 6.y.z from WineHQ repositories)
3. wine7 (wine-stable 7.y.z from WineHQ repositories)

TODO:

• [x] Decide with version should be used as latest (vanilla?)
• [x] Check if HEALTHSTATUS is always satisfied
• [x] Check if mods are working
• [x] Update README.md mentioning the possible alternatives and what the different images are there for (a table with the wine/os versions?)
• [x] Deduplicate Dockerfiles and set WINE_VER and WINE_REL as ARG?

[dcasella]

@avivace do you know if we need something like https://github.com/steamcmd/docker/blob/master/.github/workflows/description.yml to update the README on DockerHub?

(We can verify this after the PR is merged, no rush)

[avivace]

@avivace do you know if we need something like https://github.com/steamcmd/docker/blob/master/.github/workflows/description.yml to update the README on DockerHub?

(We can verify this after the PR is merged, no rush)

I remember seeing the DockerHub description being updated when we pushed to the repository, even without pushing git tags / images. I guess it's some kind of internal hook they set up (on the dockerhub side) when you "plug" the github repository in the DockerHub page (check https://hub.docker.com/r/avivace/ror2server VS their https://hub.docker.com/r/steamcmd/steamcmd, there's no "Source Repository" widget there, so they may need to push the README changes with that action)...

Do we want to remove the "Source Repository" thing there and push manually as they do?

[dubvulture]

Who gets the latest award?

• vanilla
  • More lightweight (~650MB vs ~850MB)
  • Slightly faster when starting
• wine7
  • Latest version of wine-stable (which should be... stable?)
  • (Hopefully) less errors / warnings
• wine6
  • None

Real world examples of latest:

• debian for stable release
• ubuntu for the LTS release
• node for the latest release (not LTS!)
• nextcloud for the latest release (not LTS!)

[dubvulture]

There's also the possibility of using wine-devel and wine-staging, which might make more sense instead of wine 6 and 7. Options:

• vanilla, wine6, wine7 (all stable releases)
  • 5.0.x, 6.0.x, 7.0.x
• vanilla, winehq-stable, winehq-devel, winehq-staging
  • 5.0.x, 7.0.x, 7.x.y, 7.x.y
  • not bothering with vanilla-devel (5.5.x), it's already complicated as it is
  • who gets the latest award? vanilla or winehq-stable?
• a combination of the above?
• either one of the above without vanilla?

Note: devel and staging releases from WineHQ are on a biweekly schedule.

[dcasella]

Do we want to remove the "Source Repository" thing there and push manually as they do?

No clue, I propose we leave it as it is and see.

Who gets the latest award?

~I vote for winehq-stable / wine7.~

[dubvulture]

Habemus tags:

• winehq-stable, latest
• winehq-devel
• winehq-staging

brb, updating Dockerfiles

[dubvulture]

(I just noticed you put it as a task in the PR description) Should I draft a suggestion?

🤠

[dcasella]

🤠

Let's see if it works.

[dubvulture]

README has been updated.

[dubvulture]

What about providing built images of devel and staging without adding their wine version in the name (and without pinning their version)? Just a rolling release approach, where a new image is built when a new version is available by triggering a new CI.

I'm not sure about telling people to build their own "debugging" images, I think someone doesn't even know what the magical docker run command actually does.

Or maybe at this point maybe it's more straightforward just to add an ENV variable that when set will replace wine-stable with either wine-devel or wine-staging during the execution of the entrypoint (i.e. when running docker run).

[avivace]

What about providing built images of devel and staging without adding their wine version in the name (and without pinning their version)? Just a rolling release approach, where a new image is built when a new version is available by triggering a new CI.

I'm not sure about telling people to build their own "debugging" images, I think someone doesn't even know what the magical docker run command actually does.

Or maybe at this point maybe it's more straightforward just to add an ENV variable that when set will replace wine-stable with either wine-devel or wine-staging during the execution of the entrypoint (i.e. when running docker run).

I really like that second approach. How larger would the image be in that case?

[dcasella]

Just a rolling release approach, where a new image is built when a new version is available by triggering a new CI.

How do we know when a new Wine release is available? If we can't trigger the CI automatically via some kind of hook, I wouldn't do it.

Or maybe at this point maybe it's more straightforward just to add an ENV variable that when set will replace wine-stable with either wine-devel or wine-staging during the execution of the entrypoint (i.e. when running docker run).

How larger would the image be in that case?

Understandable, but startup time would increase, and it's already awful...

[dubvulture]

How larger would the image be in that case?

Just a few bytes, you just need to modify entry.sh with some ENV checks + apt commands replacing the wine version if needed.

How do we know when a new Wine release is available? If we can't trigger the CI automatically via some kind of hook, I wouldn't do it.

A schedule somehow checking things from the repository? Or just a biweekly schedule that runs when the new devel and staging releases are supposed to be out.

Understandable, but startup time would increase, and it's already awful...

For wine-devel and wine-staging who cares, they're supposed to be run in debugging and "emergency" situations. Meanwhile wine-stable should be kept as is, i.e. installed during the build process.