GothenburgBitFactory / taskchampion-sync-server

The sync server for Taskchampion
MIT License
44 stars 8 forks source link

Adds Dockerfile and first version of pipelines #7

Closed ogarcia closed 4 months ago

ogarcia commented 5 months ago

This uploads the container to the GitHub hub as a package. Tag it with either tag in tagged versions (using semver) or the branch name in the rest.

The image is created for both x64 and ARM64 (takes about 40 minutes to compile for ARM64).

With the build.yml pipeline it simply compile the binary and save it as an artifact. If a tag is created, it uploads the artifact to the tag as tar.xz.

ogarcia commented 5 months ago

This system can be improved a little by introducing the value of variables RUST_VERSION and ALPINE_VERSION as repository variables so that when they are modified they are already applied in all pipelines without having to change them manually in each of the files. Entering these variables into the repository would have to be done by someone with permissions.

Another improvement would be to upload the container to Dockerhub and Quay, but for that you would have to create an account on each of the remotes and store the credentials as secrets.

domalex commented 4 months ago

It would be great to have docker version of the repo with an working docker-compose.yml file on DockerHub.

djmitche commented 4 months ago

Thank you! Let's see how this works, and make more PRs to make it better :)

ogarcia commented 4 months ago

Failed to upload the image of the container. Possibly it is a permissions problem at the organization level. I think I remember that if you access https://github.com/orgs/GothenburgBitFactory/packages you should see the package and modify the permissions. Also you have to make the package public because by default it is private.

Another thing you can do is to go to the settings of this repository at https://github.com/GothenburgBitFactory/taskchampion-sync-server/settings/variables/actions and create these two repository variables:

If once you have them created, let me know and I will send you a change to take those values of the variables. So that later, when you have to update the version of Alpine or Rust, you only have to touch those values and it is not necessary to modify the pipelines.

ryneeverett commented 4 months ago

I can see where the variables might be easier if a maintainer was actively managing them but I'm not sure how likely that is. Might be just as well to have more visibility and open pull requests to change them.

tbabej commented 4 months ago

I switched the visibility of the package to public, so it should be now visible to everyone. Regarding the alpine/rust version variables, I agree with @ryneeverett, better to have these just defined as part of the pipeline so that there are fewer barriers to updating.