NOTICE - V3 Upgrade

[Snider]

Hey,

When i made this action, GitHub was limited, you were limited with what you could do with composite actions.

Few years have past and with the changes with github actions, i can make the action so much better, able to support wails3, but also C++ projects.

The rewrite has been done, taking notice of how people use the action, they make a fork, mod it, use that; so I've decoupled all the processes and then added top-level orchestrators, so snider/build-action with the right config, builds a wails2 app, but, you'll probbly want to use the actions in snider/build-action/actions/*

I'll work through all the issues, and PR's bring those changes into the V3 before making a version tag for it, so people's time is respected.

[tassa-yoniso-manasi-karoto]

do you plan to continue to support v2 or just migrate to v3?

Because relying on popular libraries to support go1.23 feels more and more of a gamble but v3 still isn't stable so...

[Snider]

do you plan to continue to support v2 or just migrate to v3?

Because relying on popular libraries to support go1.23 feels more and more of a gamble but v3 still isn't stable so...

I'll continue supporting wails2; I'm sure apps will use it well past EOL; in fact "v3" branch is using wails2 and I've not added wails3 yet.

The old action behaviour can be used calling the wails2 builder directly: https://github.com/Snider/build/blob/v3/actions/build/wails2/README.md
which has the same interface as v2 & main branches, but done as callable actions, so build, package and sign are no longer in the same file no one wants to edit.

Over the next couple months I'm going to move my other CI builds to this project, as I have 2 different ways to handle Docker, a couple C++ builds and a bunch of typescript projects (with documentation sites)

You can actually pick and choose from the actions for your own flows, like: https://github.com/Snider/build/blob/v3/actions/discovery/README.md

The discovery plugin is what figures out what build stacks to use, which needs more work, but in theory you could run the build stacks for everything found in the repo, then run the wails build, so as long as the lang/build-asset is supported the top level action should mostly "just work" as a single builder for deps + app.