Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: CI improvements #17

Open
wants to merge 15 commits into
base: master
Choose a base branch
from
Open

WIP: CI improvements #17

wants to merge 15 commits into from

Conversation

matthewarmand
Copy link
Member

Opening this PR as a work-in-progress to experiment with and flesh out some potential CI improvements using Github Actions. Some general goals:

  • Run a test docker build on pull requests so we're sure the image still builds correctly
  • On pushes to master which update the README, update the description on dockerhub as well
  • lint shell scripts with shellcheck on pull requests and master pushes
  • On tags, build and tag image, and push to Dockerhub.

Been going back and forth a bit on the tagging/release workflow, whether to just trigger it off master and automate the versioning, or to have specific tags and push off that. Additionally, what versioning scheme. I'd like to get back to a more semantic versioning scheme than just tagging everything "latest". Because we could potentially have Dockerfile and entrypoint script changes which don't affect the core tizonia code, that should probably be abstracted in the versioning. So I'm thinking something along the lines of v0.21.0-1-dock1 (which will also be tagged as "latest"). This way it includes the full Tizonia version (v0.21.0-1) and has a semantic suffix for the "packaging" version (by docker). Open to feedback on all points.

TODO:

  • Set credentials for Dockerhub
  • Experiment with these workflows in this PR (Gonna have to be here unfortunately, not really a better way to test-run them)
  • Once a branching/versioning scheme is settled on here, make sure that's properly implemented and documented if necessary
  • This will probably involve a lot of experimental commits, so when this is ready to merge, definitely squash this one

@tizonia
Copy link
Collaborator

tizonia commented Mar 18, 2020

Hi Matt

I can't find anything wrong at all. I really like all the improvements that you are proposing. Just one question: Tizonia's version only includes this part: v0.21.0. So I was wondering if it would be enough for the packaging version to just add '-1' rather than '-1-dock1'. But I may be missing something.

@matthewarmand
Copy link
Member Author

Hi @tizonia , thanks for the thoughts!

Tizonia's version only includes this part: v0.21.0

The initial -1 is a side effect of the Ubuntu packaging. If you look at the Tizonia version specified in the Dockerfile, it's currently 0.21.0-1. This basically allows a new tizonia package to be published to the Ubuntu repos (or others) which involves a repackaging of an updated dependency rather than an update to the app itself.

I know there's a lot of overhead currently associated with the packaging workflow for Ubuntu, Debian, etc. So It's possible that suffix is effectively always -1. If that's the case, it could make sense to drop it, though it could be potentially confusing seeing 0.21.0-1 in Ubuntu repos and 0.21.0-2 as an udpated Docker image version (for example). While the Docker image is dependent on those Ubuntu packages, it makes a bit more sense to me personally to use that full version string as the base for the Docker image version.

There's another idea I've been kicking around that might simplify this. With the recent meson build process improvements happening in the main tizonia repo, it might be worth exploring building the tizonia source code from scratch when building the Docker image. This would potentially be a more time-consuming build than the current apt-get based one, but one advantage would be that it would de-couple the Docker image releases from the Ubuntu packaging. For example, when a new tizonia version is released, a new Docker image could be built immediately as opposed to waiting for the Ubuntu packaging to complete.

So that's just an additional thought, not necessarily saying we should do that now or that the meson build is even to the point where this would be feasible / make sense, but its potentially something to think about in the future.

@matthewarmand
Copy link
Member Author

@tizonia one thing that would be helpful from you whenever you get a chance (no rush) is to add the Dockerhub credentials to this repo as encrypted secrets per these docs with the field names DOCKERHUB_USERNAME and DOCKERHUB_PASSWORD. Thanks!

@tizonia
Copy link
Collaborator

tizonia commented Mar 23, 2020

Hi @matthewarmand

it makes a bit more sense to me personally to use that full version string as the base for the Docker image version.

I forgot that the docker image currently depends on the debian packages. So you are absolutely right. It makes sense to add the additional version suffix.

This would potentially be a more time-consuming build than the current apt-get based one, but one advantage would be that it would de-couple the Docker image releases from the Ubuntu packaging

Very good idea. As you say, it may take some more time to build, but meson makes it at least something that could be considered (autotools was leaving this option out of the picture pretty much).

Dockerhub credentials to this repo as encrypted secrets

Sure, I will have a look in the next few days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants