Docker support #1869
Docker support #1869
Conversation
Hmm...every release is a tag, so I'm not sure what you mean by this? |
When a new release is made say pre7 for example, and the last commit that is in the release has a git tag with that version number, that tag can then be transferred into the docker hub registry. |
The GitHub release system is just a layer of icing on top of native git tags. There are already git tags in the repository: |
|
my mistake, i didn't catch that. |
|
Ya, it's p-unintuitive -- my fear was that it wouldn't support prefixing every tag with "v" so I wanted to make sure we were on the same page (I assume you've been downloading from that page). |
|
I think the ideal solution would be to isolate the docker image/container creation process as much from the TShock release process as possible. We're experimenting with .NET Core and that'll have the entire process remodeled again, which would mean that either the changes would have to be applied somewhere. It's pretty easy for us to modify and maintain the workflow file we have. I believe it's possible to integrate with github such that on release create, an action can be fired that creates an image given the latest release that we publish (assuming that we maintain consistency in how we publish releases). Rather than building on docker hub, it would be built in github CI land, but that would have the advantage of not overextending our stay on the internet. I'll give it some thought over night to see if we would be able to maintain this long term with the switch to .NET core & having the build process inside the image. Docker has strong benefits for users, and I totally understand the desire to have it -- it makes total sense. At the same time, though, docker repeatedly throws sand in my face as I'm a macOS user, so I get terrible VM overhead. So, I personally wouldn't even be able to take advantage of it. Most of the "big" servers are running outside of Mono (i.e., on Windows), which is partly why we've switched back to building on github with Thank you so much for contributing this! I really really appreciate the work you've put in! I hope we're able to find a nice way to get this in gen-dev soon! |
|
The switch to dotnet core would be awesome. I am going to experiment switching my docker hub to auto build against my TShock fork. I put in the v-version scheme against the tags. After your next release, I'll see how it all hooks up. Worst case i revert back to my docker repo. |
I agree. Pryaxis provides pre-built releases every major release so building from git is not only unnecessary but also dangerous/potentially breaking (we don't want to ship unfinished code from gen-dev right?) |
|
You could have development-tagged, say `CI`, from docker. I would think
`latest` and named version tags would be triggered from the git tags,
`v5.0.0`.
This is the config I was going to try out, to give some clarity.
…On Sat, May 23, 2020, 4:32 AM quake1337 ***@***.***> wrote:
I think the ideal solution would be to isolate the docker image/container
creation process as much from the TShock release process as possible.
I agree. Pryaxis provides pre-built releases every major release so
building from git is not only unnecessary but also dangerous/potentially
breaking (we don't want to ship unfinished code from gen-dev right?)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1869 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB46ER7UWMEHDMBYAEHJAJ3RS6J2NANCNFSM4NIK7LJQ>
.
|
|
I would honestly love it if we could have docker images built for every single commit (with code changes). |
|
I relayed this to chris in discord, by the way: knowing the size of your docker download base is really important. We totally only know how popular our software is based on the number of downloads we have on github releases. While obviously we're still here, we have in the past considered shutting down operations based on the download counts from github. I'm glad we didn't because it looks like we undercounted a tiny bit. |
|
Glad you guys didnt quit. As soon as 1.4 release, I've been swamped with requests to update the container. still working out the kinks in my pipeline based on the fork. I forgot tags need to be manually updated from an upstream, but the moment i pushed them it kicked off the build. But then the build failed because i dont have the docker file on general-devel. This is what i get when my brain is mush working till 3a. With that said, I think, this setup will work. Need to merge my docker branch into gen dev. |
|
I do want to mention, I think I am hitting into frequency limits on docker hub's autobuild. It may be worth while to use github actions to build the container, and push to docker hub. |
@ryansheehan the upshot to using GitHub Actions is that we have unlimited minutes on GitHub, so we're at an advantage to using resources here. |
This PR brings over my TShock docker container from this repository. The container itself is quite popular with over a million downloads on docker hub.
I modified the dockerfile such that it runs through a build stage that follows the TShock build steps and packages it similar to what is done in the
create_release.pyscript.What is left to figure out is where you wish to publish the container? Would you like to continue to use my ryshe/terraria on docker hub? create a new docker hub account or use another registry all together? Once a registry is picked, the docs in
/docker/README.mdwould need to be updated.Docker Hub already has integration to github, and can monitor a project for changes and automatically kick off a container build. The problem is that this project hasn't maintained its git tags in a while, which will make tagging containers in docker hub impossible.
In the process of making this PR I had a couple of side thoughts. It would be nice if I could have used the release scripts to package the the assets in the build stage. That way there would be consistency between the file structure in the container and the zip published here. Currently how things are built and packaged is duplicated.
Another idea would be to move the build completely into docker. Additional stages can be added to execute automate tests. The final assets can be pulled out by creating a temporary container instance and copying build assets out. An advantage to moving the builds into docker means your autobuild agents no longer have to worry about build tool versions, and it makes switching build automation tools easy.
Let me know what you think about where you wish to publish the container, and I can possibly facilitate setting up the auto build.