Refactor github action "Zwift script files updater"

[netbrain]

Today the script files updater changes the current container image upon changes to the entrypoint script (aswell as maybe som other ones)

We should probably refactor this to trigger on changes to entrypoint and other scripts as well as the Dockerfile, where last mentioned will have to run a build from scratch instead of a simple commit.

[sHedC]

Any reason you used the testing trixie build? it is this that is failing they have broken some dependancies. I have re-built with bookworm locally and builds fine.

[netbrain]

Trixie at the time was the only variant that had the correct wine version.

[sHedC]

AHH ok I'll switch it to bookworm so it builds

[sHedC]

@netbrain Created a temporary repo to try it out, have a look see what you think: https://github.com/sHedC/buildtest/actions It uses releases to keep track of previous build incase of failure so what it does:

1. Get last release, compare changes to head see if a build is needed and what type of build (release is filtered to find auto builds)
2. If build required create a draft release (done early as build takes time)
3. Build for Update/ Full, calls separate workflows and waits for success (or fail)
4. on success commits drat release and cleans up any old draft releases

In addition it tries to generate auto release notes, so if you resolve an issue using a pull request it picks that up and documents it, otherwise just documents changes.

[netbrain]

Great work, I'll look into it someday (vacationing)

[sHedC]

Sounds like a nice long vacation hope you enjoy

[sHedC]

@netbrain - did you get a chance to review yet, I assume not.

[netbrain]

I did take a gander at it, but I think maybe you have to explain the benefits of this as opposed to what we have now in order for me to take a proper stand on it.

[sHedC]

Ok just started with re-configuring to refactor as this issue is about and to add trigger different build type based on what was changed.

So simply:

1. If only script files updated then run update (not build, same as today)
2. If files change that would require re-build, then trigger rebuild

Sounds simple but problem here is if the build fails then a future update may pick the wrong build, so idea was to create a tag and release for each successful build (with auto generated comments if possible)

Then updates would check the previous successful build with the current state and check the changed files to decide what build to run based on a successful release/ tag.

Currently it just does an update so if you update the docker file and a script you have to cancel the partial build and manually do a full build.

[netbrain]

Ok just started with re-configuring to refactor as this issue is about and to add trigger different build type based on what was changed.

So simply:

1. If only script files updated then run update (not build, same as today)
2. If files change that would require re-build, then trigger rebuild

Agreed, this is what I want to too.

Sounds simple but problem here is if the build fails then a future update may pick the wrong build, so idea was to create a tag and release for each successful build (with auto generated comments if possible)

A build may be successful, but fails when trying to start Zwift. How should we handle those? Manual intervention as it is today?

These tags, are these created manually then? Would like it to be as automatic as possible..

Then updates would check the previous successful build with the current state and check the changed files to decide what build to run based on a successful release/ tag.

Sounds complex, maybe unnecessarily so. Yes a new build today may fail and future builds may be based on this. But I think manual intervention for these might simpler than having to tag on every new release.

Currently it just does an update so if you update the docker file and a script you have to cancel the partial build and manually do a full build.

Yeah, would like to fix this shortcoming.

Would like to have a full build when Dockerfile changes. And for all other resources, run a update on change.

[sHedC]

A build may be successful, but fails when trying to start Zwift. How should we handle those? Manual intervention as it is today?

These tags, are these created manually then? Would like it to be as automatic as possible.

Tags are totally automatic, it creates a draft before starting then either deletes it if failes or completes a release if the build/ update is successful.

Sounds complex, maybe unnecessarily so. Yes a new build today may fail and future builds may be based on this. But I think manual intervention for these might simpler than having to tag on every new release.

Its complex but would be automatic, if there is a build failure and an update was done on another field that would not cause a full rebuild to fix it then it would know to do a full rebuild.

Yep its a full solution but yes also its more complex but only in the tagging the rest doing diffs would be as complex as what is there.

[sHedC]

Another option is to do what I do in another repo, I create a tag and release and its the release that triggers the build rather than just updating from every commit to main.

But I got the impression you wanted fully automated and I like the challenge.

[netbrain]

But I got the impression you wanted fully automated and I like the challenge.

Yes, i do, but not at all cost. I'll set of some time to look into it in greater detail