Automating Factorio Docker Builds

[bkuhl]

I'm interested in automating the factorio docker container production. I didn't find your docker containers before beginning some of this work. But now that I've found your repo and seeing the extensive work you've put into the docker images (well done btw) I think the community benefits the most if we work together.

I've written a micro-service that is intended to automate building these kinds of images using github/travis-ci. Here's how it works:

• Microservice checks a github repo's tags against the full game release list. Any versions that don't already have a github release will receive github releases, regardless of how old they are.
• Travis-CI would get kicked off to build the docker image, tag it and push it up to Dockerhub automatically.

Rather than fork this repo, I'd prefer to apply these updates to this existing repo if you're up for it. Here's what I would need and what would change:

• Non-stable releases would be tagged as x.x.x-experimental and only stable builds would remain x.x.x. In this case, it would create duplicates since there are experimental releases without this additional flag.
• Travis-CI would need environment variables configured with a docker username, password and email so images could be automatically tagged and pushed up. Docker automated builds don't allow dynamic tagging in this fashion.
• A github token I can use that will be used to create releases on this repo. I'd be happy to use mine if I can be granted permission

What are your thoughts?

[zopanix]

Hey,

Thanks for contributing. I honestly have no exp on travis but it seems very interested. If I'm understanding this correctly, this would mean really automated builds (docker hub's features aren't that great and flexible) I would love to integrate this to this project. Could you fork mine and make a pull request ? I can grant you access to the repo if you really need it, bud I'm curious to see how it would be.

Thx again

[zfarrell]

@bkuhl or @zopanix - do you need help with this? I'd love to see this automated and would be happy to help!

[zopanix]

@bkhul: Are you still interessted in doing this ? I sure am :) It will take me some time to react this summer because I have a lot going on for the moment. It should become calmer for me from september. But I'd be happy to see this moving forward.

@zfarrell: You're welcome to help also :)

[bkuhl]

Sure, I understand. As zfarrell mentioned we'd love to help.

I've put together an example for you on how game-watcher publishes releases - see https://github.com/bkuhl/factorio/releases.

• version numbers are prefixed with v
• non-stable builds are suffixed with "-experimental" as per the factorio build terminology

I prefer to stick with this method of tagging as I plan to support other games as well such as 7 Days to Die and would like for tagging to remain consistent.

Travis-CI is configured to tag the docker container whatever the release name is... in this case something like v0.13.8-experimental. This gets a little tricky because this repo currently doesn't use the v prefix and also doesn't use this suffix. That leaves 2 options:

• Run game-watcher before fully integrating Travis-CI so all the releases are created but no docker images are built with corresponding tags
• Rename the image tags in the current repo based on this naming scheme (recommended)

[bkuhl]

I should also mention this tool runs every hour, so normally releases would be created within an hour of the actual release.

[zopanix]

Seems really cool, I'll have a look :) I don't know how I'll manage the releases... Bud will see myself how to do this as clean as possible :)

[zopanix]

Hey again, seems really cool :) If I understand this correctly, I can't do anything myself, but if I add you as dev on this project, you could set this repo on your micro service and it would then automatically tag the repo for every version with one hour delay (which seems more then reasonable :)) If you confirm, I'll add you as dev on the repo ;) Seems cool to have every part automated

[bkuhl]

That is correct.

How do you want to handle the tags in the dockerhub repo?

[zopanix]

The recommended way :), The only thing is, we wont be able to rebuild the "very" old versions :p

[bkuhl]

In that case, I'd say don't rebuild them, just pull them, retag them and push up the new tag. Once the new tag is pushed you can delete the old image. It's a big of a pain - I can do this if you'd like - but it would ensure that none of the older containers get changed from their original state.

[zopanix]

Ok, I'll see if I can make a script for doing so, But I'll do it tomorrow at work, my internet connection isn't that good at home... It would really take me ages to do this

[bkuhl]

Sounds good. I'm in the same scenario. We'll also need Travis-CI to have the environment variables configured so it's able to build/push new containers.

[zopanix]

You can now do things on the repo :p, I'm starting migration of tag

[zopanix]

Retagging docker hub images has been done. I'll let you do your stuff :) This means that your part should do the following:

• change version in readme
• change version and sha1sum in Dockerfile
• commit these changes, tag the repo
• push everything upstream From there on, travis ci will automatically build the new image and push it as latest and with the right tag

[bkuhl]

I didn't realize the dockerfile was using a sha1 - is that a recent addition? I'll need to make some updates to the microservice.

[zopanix]

It's been there for some time now. Ever since I've migrated to alpine

[bkuhl]

I ran the script that created all the releases. v0.12.8 is considered the latest since it was tagged the last. Not all 0.12.x are experimental - see https://www.factorio.com/download-headless/stable.

I don't have it updating the Dockerfile automatically, so we'll want to make sure to follow the convention v0.x.x / v0.x.x-experimental for now with manual releases/tags to avoid the watcher from publishing duplicate releases. I'll put some time this week into automatically cloning the git repo and updating the docker file.

[zopanix]

Ok, perfect, I'll be carfull when tagging releases

[bkuhl]

I added sha1/version updating in the Dockerfile (see https://github.com/bkuhl/docker_factorio_server/commit/ba0ac0509d477a58dca40866ba5631dee505ecd3). The downside is that it doesn't go through a PR and would need to be done directly on master.

[bkuhl]

I think this does it though... after pushing the changes to master it'll create the release and call it done. I'm thinking it'd be good to remove the latest version from the readme since it will essentially always be the latest. Thoughts?

[bkuhl]

The application has been deployed. I expect it to work, we'll find out with the next release ^_^

[zopanix]

Hey, it doesn't seem to work, there have been two releases since. I'm reopening this :)

[bkuhl]

Bummer - I'll look into this today.

[bkuhl]

Issue has been resolved, I still had it pointing to my test github repo :-\