chore(ci): refactor indiv jobs

[YOU54F]

Building individual targets allows us to identify where a single one fails, and gives us quicker feedback.

This mitigates some of the issues seen when building multiple targets with cross (wrong linker symbols), and allows us to enable per target caching which improves compile times.

Few other quality of life improvements are included (cron job, smoke test to weed out loading issues with the shared libraries)

• update release workflow to support

  • workflow_dispatch
  • cron schedule every wednesday
  • run each target in seperate job
  • add cache key per target

• update release scripts (pact_ffi / verifier_cli )

  • allow building individual targets
  • refactor similar steps
  • generate musl .so with RUSTFLAGS="-C target-feature=-crt-static" fixes 0.4.20 pact_ffi - aarch64-musl .so failing to load (missing symbols) #436
  • smoke test dynamic lib loading (for pact-php, pact-js, pact-net, pact-go) fixes 0.4.20 pact_ffi - aarch64-musl .so failing to load (missing symbols) #436

Breaking changes

BREAKING CHANGE: macos aarch64 binaries now renamed to <app_name>-macos-aarch64. (previously was apple-darwin for aarch64)

Rationale: for consistency with x86_64 apple target and other platforms

BREAKING CHANGE: macos binaries are now only published with <app_name>-macos-. osx flavoured varieties are now discontinued

Rationale: for consistency with nomenclature, as osx not relevant today with latest version being macos 14

BREAKING CHANGE: sha256 files no longer contain full paths to files, only filenames

Rationale: The additional information is superfluous for end users, and requires them to modify the file for it to be usable. see pact-net

[rholshausen]

I hope you know what you are doing!

[JP-Ellis]

Since release builds can be significantly slower, should this still be only selectively enabled?

[YOU54F]

so originally when I was able to build for multi targets with cross in a single run, but I actually run out of disk space on the gh runner because the debug build folder was so large (and also results in a hefty cache to store and retrieve).

this workflow is only for building the released artifacts, until this PR where it does the most basic of smoke tests.

the actual build ffi workflow builds and tests the ffi lib cross plat (although not all of our targets, just x86_64 win/lin/mac)

so the rationale was if this is able to smoke test a full release wf before each target is actually released (so via the PR workflow), we actually know whether it will work when we push a release tag.

Maybe we could just run debug on the pr's, but run in release mode on master, so before someone does push a release tag, they have confidence it will just work (tm)

I feel like we could actually probably consolidate some of our workflows to avoid de-depulication, and maximise our caching potential. we have a pact rust workflow which tests everything, pact ffi workflow that builds the project with cmake (which we don't use in the release workflow), and c smoke tests on linux against.

[JP-Ellis]

If we cache the CARGO_TARGET_DIR, we would likely get most of the speed up anyway. The compiler would not need to recompile most of the dependencies in the first place.

[YOU54F]

I hope you know what you are doing!

😅

I've given it a good smoke test across all the projects consuming it that are in my immediate radar (pact-js-core / pact-php / pact-net / pact-ruby-ffi / pact-go )

It's certainly reduced my feedback loop and helped me diagnose single target failures, and hopefully this should mitigate some of the initial concerns we get from maintainers on a new update. it's bork and we don't know, and have to go through the release shenanigans again with a fix that may or may not work (when its something in the cross compilation build process, that is a bit of a black box without being prepared to go really deep in yak shave territory)

I write up some release notes for the release page when this drops if it doesn't pick up my breaking change footer