Closed bkuhl closed 8 years ago
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
@bkuhl or @zopanix - do you need help with this? I'd love to see this automated and would be happy to help!
@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 :)
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.
v
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:
game-watcher
before fully integrating Travis-CI so all the releases are created but no docker images are built with corresponding tagsI should also mention this tool runs every hour, so normally releases would be created within an hour of the actual release.
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 :)
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
That is correct.
How do you want to handle the tags in the dockerhub repo?
The recommended way :), The only thing is, we wont be able to rebuild the "very" old versions :p
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.
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
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.
You can now do things on the repo :p, I'm starting migration of tag
Retagging docker hub images has been done. I'll let you do your stuff :) This means that your part should do the following:
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.
It's been there for some time now. Ever since I've migrated to alpine
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.
Ok, perfect, I'll be carfull when tagging releases
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
.
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?
The application has been deployed. I expect it to work, we'll find out with the next release ^_^
Hey, it doesn't seem to work, there have been two releases since. I'm reopening this :)
Bummer - I'll look into this today.
Issue has been resolved, I still had it pointing to my test github repo :-\
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:
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:
x.x.x-experimental
and only stable builds would remainx.x.x
. In this case, it would create duplicates since there are experimental releases without this additional flag.What are your thoughts?