Upload binary release artifact per commit

[jerrymarino]

This PR adds the ability to upload release artifact via XCHammer's github
CI and it creates a release when pushing a tag to v*

The github actions API doesn't play well with per commit artifacts. For
now we create a release when pushing a tag.

Consuming the per commit artifacts w/o the github actions API is blocked
by this: actions/upload-artifact#50

[jparise]

What are the tradeoffs between doing this per-commit versus with explicit versions and tagged releases?

[jerrymarino]

@jparise I don't think the 2 are mutually exclusive and it's useful to have a per commit and per release artifact. When folks are running on HEAD of a repo this makes it easier to pull and use it for consumption w/o having to build out of band. I don't know about you but I can't count the times where I needed to test code on github and ended up having to build on my own because they didn't have per commit and PR release artifacts.

XCHammer has a lot of minor but necessary commits. Its hard to draw a line in what a release would be as builds are often backwards and forwards compatible with Bazel and rules. IMO if there's a commit landing into master or even a PR someone will need the build! Even in rare some cases, I need to pull a XCHammer PR into Pinterest.app and run it on internal PR validation.

I'm not opposed to cutting releases more often or we have a large milestone e.g. tested Bazel version. If we only had a per release artifact we'd then need to create a lot of releases to pull the artifact

rules_apple and rules_swift got away from releases altogether. Now, it's hard to tell what Bazel version they will work with, which could be advantageous in a stable future. PodToBUILD releases are basically commit level but versioned with a tested Bazel version. It's a huge pain point for myself and other users of PodToBUILD to have to cut releases just to get the build artifact or test changes.

Only release

• someone needs to create many releases for very small changes
• irregular schedule and commits are driven by external and internal teams
• github send release notifications to watchers

No release / only per commit

• easily test and consume bleeding edge commits or PRs from internal and external users
• hard to know what a reasonable commit you should use as a newcomer or external person
• some commits in a larger series e.g. a long series of API breaking changes are better avoided

Both

• easily test and consume bleeding edge commits or PRs from internal and external users
• retain the notion of a release - which might line up with a relative Bazel version like PodToBUILD

[jerrymarino]

I've additionally added the ability to upload a release artifact when pushing a tag v*

The github actions API doesn't play well with per commit artifacts. For now we create a release when pushing a tag.

Consuming the per commit artifacts directly with Bazel w/o the github actions API is blocked by this: actions/upload-artifact#50

I've added a detailed description of how to create a binary check in or local repository using the per commit artifact to the README.