Build artifacts expire, we should create github releases instead

Everything is in issue title. Here's an example of expired artifacts:
https://github.com/GabLeRoux/macos-crossover-wine-cloud-builder/actions/runs/1104195381

They are listed, but cannot be downloaded anymore:

possible action to use:
https://github.com/actions/create-release

Yes artifacts have I think a 2 month? life before expiring.

I had considered being this up but I think we’d need to check how brew provided libraries are getting linked as brew isn’t exactly known to keep things stable.

I just tried something on a similar project which builds an older open source game on a mac and I managed to automate releases creation (we need to first move the artifact out of the mac and then create a release from the downloaded artifact). Here's a draft pr I tried between two tests execution at my day job 😅:
shoogle/OpenArena-legacy#2

Come back to this and thinking it over I’m against providing prebuilt releases due to how much of a PITA doing it was when using macports libraries let alone dealing with brew segregated libraries.

As the provided local build script already does everything needed I don’t believe it’s worth the additional effort.

@dasmy & @GabLeRoux any thoughts?

I might be wrong, but I feel that it's mainly a matter of creating a github release when pipeline succeeds on main branch. This can be done with the example I shared above.

I don't think we must support all versions or all latest versions. I don't want any pressure on that project. Providing a release would definitely solve the expiration of builds problem.

When I started this project, my main objective was to get a binary without having to install and build everything from my laptop. It was just a fun weekend project and I consider it already succeeded the objectives.

If we think about it with iterations, the main problem I wanted to solve in current issue is the expiration. Maintenance and making sure we always have the latest version is a different issue imho.

Simple 1st iteration:

Create a release each time the pipeline succeeds on main branch based

I’ll expand on my concern with provided releases.

Once compiled wine will have backend in library paths these may be pointing to the actual path and not brews /usr/local/opt paths this can cause issues later when a libraries version gets bumped making the embedded path now invalid.

Also need to ensure anyone using the release have installed the needed runtime libraries or ship them within the package.

I agree with @Gcenx that there are severe difficulties to be expected. Currently, a user of the artifacts needs to have the very same versions of the runtime dependencies installed via brew which were present at build time on the CI server.

Thus, for providing usable release packages we would need to

identify all runtime-dependencies and prepare an installation of all these packages in our release folder (see https://github.com/Homebrew/brew/blob/664d0c67d5947605c914c4c56ebcfaa80cb6eca0/docs/Installation.md#untar-anywhere for warnings against that)
inside this folder patch all binaries with install_name_tool to have proper relative rpath entires (similar to

macos-crossover-wine-cloud-builder/.github/workflows/build_monolithic.yml

Line 369 in f7d2bd4

install_name_tool -add_rpath @executable_path/../lib wine64

)
do the same for crossover, so that during execution it does not use the system brew but the brew libs we are shipping.

If I did not forget anything serious, I think this could be doable and the final release packages would profit from this. Still, it would be challenging and a bit of work...

@dasmy I’d ignore what brew says about a none default install location as we’d be fixing up the installed library's install_name after the fact.

When installing brew into a custom location there bottles lightly won’t work forcing source compiles that they don’t support.

Still brew doesn’t recommend this proposed setup, it recommends not relying on brew provided libraries.