Github action composite actions

[wileyj]

etc.

some interesting ideas came up in this PR https://github.com/stacks-network/stacks-blockchain/pull/3199 that i think would make a good issue to work on for the next iteration. Saving the links from that PR here, along with another filed issued around the use of osxcross: https://github.com/stacks-network/stacks-blockchain/issues/3208

Desired end result will be that most of the jobs/steps would live outside of the stacks-blockchain repo, making it easier/faster to update the logic used for building.

Further, this issue should also be used to track reducing some repeated jobs (work on that was skipped for #3199 - for example, there are 2 actions to build docker images for alpine and debian. they should be able to be combined into a single file.

Links saved from the PR: https://github.com/stacks-network/stacks-blockchain/pull/3199#discussion_r925141644 https://github.com/actions/upload-artifact https://github.com/actions/download-artifact https://github.com/stacks-network/stacks-blockchain/tree/806d99556432b9755d332d2526cf2e0d88b87847/.github/actions/dockerhub https://github.com/hirosystems/clarinet/blob/develop/.github/workflows/ci.yaml

https://github.com/stacks-network/stacks-blockchain/pull/3199#discussion_r926971003 https://github.com/hirosystems/stacks-wallet-web/blob/dev/.github/actions/provision/action.yml

https://github.com/stacks-network/stacks-blockchain/pull/3199#discussion_r925117228 https://docs.github.com/en/actions/creating-actions/creating-a-composite-action https://github.blog/2022-02-10-using-reusable-workflows-github-actions/#key-differences-between-reusable-workflows-and-composite-actions https://github.com/hirosystems/stacks-wallet-web/blob/dev/.github/actions/provision/action.yml

[wileyj]

look into ways to adjust pre-release on the github release action so that it sets pre-release to false only when a release is tagged with the expected versioning.

https://github.com/stacks-network/stacks-blockchain/pull/3199#discussion_r946800332

[wileyj]

https://evilmartians.com/chronicles/build-images-on-github-actions-with-docker-layer-caching from @ceramicwhite

have to evaluate if using cache layers from previous builds is viable (would also need to adjust the dockerfiles to not use ramdisk for some/all steps)

[wileyj]

One other idea to pursue is if we should enable release builds when a semver style tag is added. i.e. push a tag of 2.05.0.3.0 -> release build is triggered, binaries built, uploaded to release page, docker images built and tagged with the semver. This could be controversial though, so will need to be vetted and discussed if it's a route we want to take.

[wileyj]

tagging @CharlieC3 and @deantchi for additional ideas for future iterations

[wileyj]

now that 2.1 is released, will start looking into this as part of #3199 post work

[wileyj]

completed