feat: Use hybrid approach depending on runner

[andreiborza]

Background

This PR changes the architecture of the GitHub Action.

Prior to release 1.10.0, the GitHub Action was only available for Linux based GitHub Action runners, limiting the reach of our Action.

With release 1.10.0 the architecture was switched from being a Docker based GitHub Action to a composite GitHub Action. While the bulk of the JavaScript that runs was pre-built, the key piece of the action (@sentry/cli) was installed on each invocation of the action. This takes a long time, but allows us to support a variety of GitHub runners, for example runners running on macOS and Windows.

The hit to execution time (in some cases the action ran 2x as long as before 1.10.0) and the lack of control over the runner environment and what packages are available (e.g. node, npm, yarn...) meant that many users could not use this new architecture out of the box.

On the other hand, we also want to continue supporting non-Linux GitHub Action runners.

Therefore the architecture has been changed to a hybrid approach.

• For Linux based runners, a pre-published Docker image will be downloaded and executed. This should match behavior prior to 1.10.0
• For non-Linux based runners, the composite action architecture will run similarly to 1.10.x with a difference: node will now always be set up using actions/setup-node regardless of a node version already existing to ensure the action can install @sentry/cli and run the JavaScript script.

Workflow

The development workflow has thus slightly changed as well:

1. Create a branch
2. Run yarn set-docker-tag-from-branch to set a docker tag based on your git branch name. This is important so that the action gets its own Docker image, allowing you to test the action.
3. Make changes
4. If possible, add unit and E2E tests (inside .github/workflows/build.yml)
5. Run yarn install to install deps
6. Run yarn build to build the action
7. Commit the changes and the build inside dist/

If you forget to run yarn set-docker-tag-from-branch the repo's pre-commit hooks will do it for you and fail the commit.
Just add the changes to staging and commit again.

[Lms24]

I didn't yet look at the code changes (will do so right after) but I just had an idea:

After you create a branch ALWAYS run yarn set-docker-tag-from-branch.
This is very important.

This immediately raised a red flag tbh because I'm quite sure that I personally would forget this, even after having reviewed this PR. So chances are high someone else would forget this, too.

Can we use the post-checkout git hook to ensure this is done automatically?

[andreiborza]

I didn't yet look at the code changes (will do so right after) but I just had an idea:

After you create a branch ALWAYS run yarn set-docker-tag-from-branch.
This is very important.

This immediately raised a red flag tbh because I'm quite sure that I personally would forget this, even after having reviewed this PR. So chances are high someone else would forget this, too.

Can we use the post-checkout git hook to ensure this is done automatically?

I added pre-commit hooks for formatting, linting and automatically setting the docker tag based on branch name, all of which are skipped in the case of committing the master tag back for master CI runs.

[Lms24]

Nice, thanks for adding the pre-commit hooks!

[andreiborza]

Please don't merge this PR yet. I want to ask some users to give it a spin.

[andreiborza]

This PR will stay open for a week until March 6th to give users, who graciously helped out testing the PR, a chance to migrate off of it, after which it will be closed in favor of: #265

[andreiborza]

This PR has been duplicated and merged (see #265).