Build Changes

[adamboutcher]

I'm proposing a change to the builds to be a little more end-user friendly.

dev

This will be a quick binary only build; this wont be uploaded with any version details built on push to dev branch, aimed at testing the latest changes only

unstable

This will be a full build process, uploaded in the same way as the current dev builds, sticking with the dev-version naming scheme and available via containers etc under the dev tags.
This should always be merged from dev once we're happy with changes, potentially fix a version and push minor fixes once we hit a milestone but not add any features unless they've gone via dev.

stable

This will be the full stable build, this should always be merged from unstable, a branch should be taken with the version ID too, so people can pull a static'd branch if required.
This will be the "latest" and version numbered builds and the only builds pushed up to snap etc

This will require some changes to the build workflow/actions, but hopefully, it means we can have stability but also an easy way for people to push in changes without triggering a 3-4hr build each time.
Thoughts?

[jemand771]

When I set up a release workflow like this, I usually only use two branches (instead of the three we currently have):

• PR to dev -> test without release
• push to dev -> release as preview
• PR to main -> test without release
• tag created on main -> release as stable
  However, that only really works when you're creating your releases/tags manually.

In case we want to keep the current behavior of auto-creating tags/releases, your suggestion sounds good for push events. One thing to consider is that we should probably still run all tests on all PRs (including from feature branches/forks to dev) - so ideally, PRs would still execute a full build, just without the release. (This also means we can probably drop docker builds for PRs as they aren't tested as far as I can tell)

[jemand771]

oh, one more note: I personally find the version.txt to be a really ugly way of specifying a release's target version. sadly I can't come up with any way of doing it better

[adamboutcher]

Yes, I would still keep the tests and a binary build on dev as they're fast and easy, just not have a versioned release.

[jemand771]

This might be a bit of a longshot, but:

How did you (anyone reading this) deploy statping when using it? I use docker for pretty much everything because it's really convenient. Do we need to build and provide binaries for everything, or could we consider switching to only docker releases?

This would bring a lot of other changes with it (e.g. not needing the Makefile anymore at all) and would obviously be quite a step back compatibility-wise. On the other hand, building statping(-ng) from source would get a lot easier that way - just docker build . and that's all you need (I know you can do that already, but that doesnt't "test if every kind of build is working" if you know what I mean)

(I realized that this would break a lot of things such as tests and basically all github actions workflows. This is probably a bad idea but I'm leaving it out here anyway )

[adamboutcher]

So I purely use the docker images, however the binaries for other systems are a simple addition and give lots of deployment flexibility, such as snaps and deployments in windows environments. I can also see how the binaries could help if people with to develop an appliance style product too (such as arm and a Raspberry Pi).

[jemand771]

Ideas about docker builds:

• What's up with the base and vue docker tags? I don't think we actually need them since docker can cache the layers anyway
• Additionally, why two dockerfiles? Dockerfile.base already uses multi-stage builds, why not put the frontend and backend stages into the main dockerfile aswell?
• About docker build times: A "host" docker build (docker build --no-cache . natively) takes about 5 minutes on my pc. a cross-build using qemu for linux/arm64/v8 (just as an example) tages ~25 minutes.
  • note that when "cross-building" for linux/amd64, buildkit is smart enough to not use qemu -> 5 minutes aswell -> no extra handling needed on our side
• suggestion: make use of https://github.com/docker/metadata-action in github actions - I've used that before and I think this could work here. (simplify docker tag generation)

Suggestion about shortening build times: we can still create a docker build on dev, just not as a multi-arch image since that's the part that actually takes forever

[adamboutcher]

* What's up with the `base` and `vue` docker tags? I don't think we actually need them since docker can cache the layers anyway
* Additionally, why two dockerfiles? `Dockerfile.base` already uses multi-stage builds, why not put the `frontend` and `backend` stages into the main dockerfile aswell?

No idea but we can try combining and reducing them down. I'm not entirely sure what they're all doing yet.

* About docker build times: A "host" docker build (`docker build --no-cache .` natively) takes about 5 minutes on my pc. a cross-build using qemu for linux/arm64/v8 (just as an example) tages ~25 minutes.
  
  * note that when "cross-building" for linux/amd64, buildkit is smart enough to not use  qemu -> 5 minutes aswell -> no extra handling needed on our side

* suggestion: make use of https://github.com/docker/metadata-action in github actions - I've used that before and I think this could work here. (simplify docker tag generation)

This is all past my knowledge of docker/github 😆

Suggestion about shortening build times: we can still create a docker build on dev, just not as a multi-arch image since that's the part that actually takes forever
That could work and it might be easier for people to test changes in dev, however I'm worried people might expect dev to be cutting edge but guaranteed working code, hence my suggestion to make dev builds from unstable and have that slightly more working than some of the potentially broken dev builds.
Keeping the dev tag for unstable makes it a drop-in replacement for normal statping, although this could be considered a new feature/branch by us and the pure drop-in is down to compatibility etc.

[adamboutcher]

So at the moment the test-postman-sqlite runs on a prive runner as it was failing on ubnuntu-latest however it seems to work on my own fork, I might move it back.

I'm also testing a 32bit for windows and mac.

If anyone knows how to build for M1 Mac then that would be good too...

[jemand771]

oh, interesting that it doesn't work on the github-hosted runner.
I think it would make sense to only use the github-hosted runners (if possible). this ways, the workflows continue to work in forks

[adamboutcher]

It's worked on my personal fork, so maybe it was originally a bad image...

It looks like I've got builds for Mac 64bit, 32bit working, Windows 64bit and Windows 32bit. Mac arm64 (M1 possibly).

I'll copy my changes in once I'm confident they work.

[adamboutcher]

Judging by the tests I've done, Mac builds are really wobbly with the xgo action, however there is a fork that have darwin-arm64 support but its not on github marketplace actions...

[jemand771]

Sounds good! You can just edit the workflows that are currently in place, I'll manually make tha changes to the "new" workflow once I get to that point.
About the mac builds: It would probably be best to find someone with a M1 mac to test this. Also, as far as I understand it, M1 macs can just run docker images built with qemu and --platform linux/arm64, so at least that should work as-is (once I get buildx working the way I imagine in github actions)

Minor personal note: I'm going to be somewhat busy with exams and lots to do at work for the next couple of weeks so it's possible that things like #17 are going to take a while for me to complete. I'm not dead and I still want to help, just taking it slow for now ^-^

[adamboutcher]

I have a test M1 Mac Mini at work that I could try with (provided I don't fill it with "junk").

Good luck with your exams!

[adamboutcher]

We will have (Ubuntu) Snaps working soon, I have the build process working properly now.