r-wasm / actions Goto Github PK

Would be nice to have a index.html explaining simple steps on how to use the custom repo

Thanks again for working on the workflows!

I've read through the documentation on rwasm GitHub Actions and Getting Started. One of the takeaways I had for repository deployment is it needs to be in a standalone repository that is geared toward having multiple R WASM binary packages present. That is, we cannot pair the action with an already existing R package repository.

So, I went off and investigated whether the workflow action could be easily deployed inside an existing package repository that has multiple workflows already present (e.g. pkgdown, r-cmd-check, et cetera). The hope is to further decrease the barrier of entry by chaining usethis::use_github_pages() (to setup GitHub Pages automatically) alongside the usethis::use_github_action() (to retrieve the deployment action). I'm particularly eyeing a custom function inside of usethis (c.f. r-lib/usethis#1932).

However, after a couple of changes:

1. modifying the existing workflow to create a package list directly from the DESCRIPTION file (e.g. packages: '.')
2. enabling deployments from the main/master branch to the github-pages environment

I still couldn't get the action to publish the archive onto GitHub pages.

After multiple attempts, I switched over to directly working with the r-wasm/actions/build-rwasm action and managed to get the repository up and running by using:

# Workflow derived from https://github.com/r-wasm/actions/tree/v1/examples
# Need help debugging build failures? Start at https://github.com/r-lib/actions#where-to-find-help
on:
  push:
    # Only build on main or master branch
    branches: [main, master]
  # Or when triggered manually
  workflow_dispatch: {}

name: Build WASM R package and Repo

jobs:
  deploy-cran-repo:
    # Only restrict concurrency for non-PR jobs
    concurrency:
      group: r-wasm-${{ github.event_name != 'pull_request' || github.run_id }}
    env:
      GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build WASM R packages
        uses: r-wasm/actions/build-rwasm@v1
        with:
          packages: "."
          repo-path: "_site"

      - name: Deploy wasm R packages to GitHub pages 🚀
        if: github.event_name != 'pull_request'
        uses: JamesIves/[email protected]
        with:
          clean: false
          branch: gh-pages
          folder: _site

I think a few folks would be interested in a workflow similar to the above. So, a few quick questions:

1. Would you be okay to include this as an example under examples/?
2. Do you see any glaring issues with moving toward a per-package webR CRAN repository compared to a multi-package single repository for the organization?

Demo script and screenshot showing working installation with webR REPL Editor

# Check if package `{demorwasmbinary}` is installed
"demorwasmbinary" %in% installed.packages()[,"Package"]
# Install the binary from a repository
webr::install(
  "demorwasmbinary", 
  repos = "https://tutorials.thecoatlessprofessor.com/webr-github-action-wasm-binaries/"
)
# Check to see if the function works
demorwasmbinary::in_webr()
# View help documentation
?demorwasmbinary::in_webr

I was trying to setup github action to build R package for werbr. I got following error.

Run r-wasm/actions/build-wasm-packages@v1
  with:
    strip: c("demo", "doc", "examples", "help", "html", "include", "tests", "vignette")
    packages: packages
    upload-image: true
    upload-repo: true
Run /usr/bin/R --silent -e 'install.packages("pak")'
  /usr/bin/R --silent -e 'install.packages("pak")'
  /usr/bin/R --silent -e 'pak::pak("r-wasm/rwasm")'
  shell: bash --noprofile --norc -e -o pipefail {0}
/__w/_temp/34ffc0ae-0eea-4442-bb8f-4d27b73f4a11.sh: line 1: /usr/bin/R: No such file or directory
Error: Process completed with exit code 127.

• yml file here

Related:

• actions/build-wasm-packages/action.yml

  Line 43 in 2048a2b

  name: wasm-repo

• actions/build-wasm-packages/action.yml

  Line 49 in 2048a2b

  name: wasm-image

Even if the actions are small (ex: download-repo, download-image which could both be composite actions with a single step each), we should try to minimize the opportunity for users to make mistakes.

When first reading the docs, I thought it was a typo as the example had used my-wasm-repo and the artifact was named wasm-repo.

• Action should have param that allows for setting Dependencies.
  • (currently) Defaults to NA style behavior
    • Add DESCRIPTION option Config/rwasm/dependencies: FALSE (or TRUE) ?
• Set as params or have params override description defaults

For build-wasm-packages's packages input parameter, I am wondering what the underlying motivation for using a new/unfamiliar file format.

I'm not against it, just want to understand it.

• packages ('packages') - A file path to a text file containing a list of R package references.

Currently, r-lib/actions's setup-r-dependencies has three locations to where it will look for packages to install.

• needs - Config/Needs fields to install from the DESCRIPTION, the
  Config/Needs/ prefix will be automatically included.
• packages: - default deps::., any::sessioninfo. Which package(s) to
  install. The default installs the dependencies of the package in the
  working directory and the sessioninfo package. Separate multiple packages
  by newlines or commas.
• extra-packages - One or more extra package references to install.
  Separate each reference by newlines or commas for more than one package.

1. It will look for Config/Needs/<NEEDS> via the needs parameter.

2. packages is a default that hardly anyone sets manually because in the context of checking an R package, this field should not be changed. (You will typically always want to install deps::., any::sessioninfo

3. extra-packages is used by authors who do not want to clutter their DESCRIPTION file or for one-off changes.

If possible, I'd like to leverage r-lib/actions existing approach.

If r-wasm/actions is to be used within R packages, then I'd like to utilize the DESCRIPTION's Config/Needs/wasm field as the typical entrypoint, with a backup of packages or extra-packages.

If r-wasm/actions is to be used within a localized wasm-friendly CRAN repo, then packages file is a great choice for providing information.

If using a packages file, should it ever contain more fields such as description or R version or any other meta data? If so, should we upgrade the file to a yaml (to support comments) or DCF file (similar to the DESCRIPTION file)?

Would remove the need to constantly install pak and rwasm in action step.

Instead, whenever r-wasm/rwasm updates, the webr package should be updated.