Document how to do custom system installs

[mpadge]

@assignUser I don't even know if this is possible with the current docker-based composite action, but there'll definitely be a need for people to insert their own custom system installation steps. Thoughts?

[assignUser]

You deleted the section I wrote on that topic from the README :P

Advanced Usage

If you want to customize your workflow in a way not possible with the inputs provided, you can use the container supplied by this repository as a base for a custom workflow.

A simple example using the check.R file from this repository:

name: pkgcheck

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref }}
  cancel-in-progress: true

on: 
  # Manual trigger
  workflow_dispatch:
  # Run on every push to main
  push:
    branches:
      - main
  # Run on every PR to main
  pull_request:
    branches:
      - main

jobs:
  check:
    runs-on: ubuntu-latest
    container: ghcr.io/ropensci-review-tools/pkgcheck-action:latest
    env: 
      GITHUB_PAT: ${{ github.token }}
    steps:
      - uses: actions/checkout@v2
      - name: Run pkgcheck
        id: pkgcheck
        run: source("check.R")  # adjust path to script here
        shell: Rscript {0}
      - uses: actions/upload-artifact@v2
        with:
          name: visual-network
          path: "${{ steps.pkgcheck.outputs.visnet_path }}"
      - uses: actions/upload-artifact@v2
        with:
          name: results
          path: "${{ steps.pkgcheck.outputs.results }}"

[mpadge]

But that merely uses the container's entrypoint, but doesn't modify the container in any way. What would be needed would be a way to modify the actual container via apt. Imagine somebody needs to run their own customised version of your R/install.R script - would that be possible?

[assignUser]

They could either use run: to install additional stuff during the job (which is run inside the container unless a step specifies another container), that would ofc only be during the job.

If they want to prepare their own container they can just PULL the pkgcheck-action container in their Dockerfile and go from there.

Edit: A small correction, using the above workflow does not call the ENTRYPOINT (in this case check.R) it only uses the container.

[assignUser]

This could also be used to cache dependencies for packages with large, complex dependencies.