Reusable workflows

[schloerke]

Fixes #4
Fixes #6

Previously, two actions needed to run in different jobs. To pass information from one job to the next, it required using an artifact. The build job required a special GitHub package docker container to run in. It felt like there was a lot of user opportunity to miss a line of code.

PR Updates

• Removed build-wasm-repository action
• Removed download-wasm-artifacts action
• Added build-cran-repo and build-file-system-image to build a wasm CRAN repo or wasm image bundle.
  • Action will save to repo-path or image-path respectively.
  • repo-path defaults to _site; image-path defaults to .
  • Having independent actions allows for better documentation for each intended purpose.
  • Both actions use an internal action (.github/actions/build) that uses a docker file for the single action step. This requires the runner to be ubuntu, but the user can compose build-repo or build-image steps how ever they want.
• Added reusable workflow to upload wasm image bundle files (via .github/workflows/release-file-system-image.yml)
  • packages input defaults to file::.
  • If Config/Needs/wasm is in DESCRIPTION file, those packages are automatically included.
• Added reusable workflow to upload wasm CRAN repo and deploy to GitHub pages (via .github/workflows/deploy-cran-repo.yml)
  • If packages is empty, then the ./packages file is used as input.
• Added examples for each reusable workflow.

Actions in action

• On release: add image files as release asset files.
  • Workflow: https://github.com/r-wasm/actions/actions/runs/7052820156/job/19198700903
  • Release: https://github.com/r-wasm/actions/releases/tag/barret
• On push, build repo and deploy to gh-pages website
  • Workflow: https://github.com/r-wasm/actions/actions/runs/7052792018/job/19198613732?pr=8

Questions

• Are action names ok? <VERB-THING> (build-repo and build-image)
• Are workflow names ok? (build-and-deploy-repo.yml and release-image.yml)
• Is it ok now that we are using a docker step vs using artifacts to transfer files from a build step to a deploy step?
• What is a good default for strip when making a library bundle?

[georgestagg]

I'm seeing an issue using one of the reusable workflows from another repo, due to the use of local action references, so I'm going to hold off merging for now.

I'll continue working on this tomorrow -- I see a way forward but will need to tweak things slightly.

[georgestagg]

Okay, so in testing this PR I hit the following issue: actions/toolkit#1264. Essentially, it means we must be very careful using local actions in workflows intended to be called and used by unrelated remote repos.

To work around it, I've had to simplify the workflow and actions so that the workflows call the build-rwasm action directly, rather than indirectly through other actions. This should be okay, because the previous actions were simply thin wrappers around the functionality built into build-wasm with this PR.

In addition, the reference in the workflows now contains a v1 tag explicitly. Unfortunately, we must remember that this is in place in the case of future testing and updating. There does not seem to be a simple way to get the tag requested by the caller. Quoting from the issue linked above:

Since the github context is always associated with the caller workflow, the reusable workflow cannot access the reference, for example the tag v1

This PR has now diverged quite a bit from main, so I am going to be pragmatic and merge it as-is. That way, we can get the reusable workflows up and running, and revisit the problem issues above in the future using simpler and cleaner PRs.