Add an action to flag an TODO, FIXME, etc. in code comments

Define by LoC changed?

Image name is breaking due to incorrect shell interpretation

see: https://github.com/RMI-PACTA/workflow.pacta.actions/actions/runs/7958651870/job/21724887289

Run echo $ghcr.io/rmi-pacta/workflow.pacta.actions
  echo $ghcr.io/rmi-pacta/workflow.pacta.actions
  docker pull $ghcr.io/rmi-pacta/workflow.pacta.actions
  shell: /usr/bin/bash -e {0}
.io/rmi-pacta/workflow.pacta.actions
invalid reference format
Error: Process completed with exit code 1.

like this https://github.com/RMI-PACTA/pacta.portfolio.allocate/blob/main/.github/workflows/pkgdown.yaml

I go back and forth on if this is a good idea or not.

I find CSpell useful while coding, since it can work on both normal prose (.md, .txt, etc) and on code files (.R, etc) while being pretty good about dealing with coding conventions, like snake case.

https://cspell.org/docs/how-it-works/ lays out:

The concept is simple, split camelCase and snake_case words before checking them against a list of known words.

which is great, but leads to my single biggest frustration when dealing with CSpell: maintaining the custom word list. Overall, it's not that difficult, since CSpell traverses up the directory tree until to find custom dictionaries, which means keeping a wordlist in the repo root, and updating it when new words are added to the repo.

I don't have any benchmark as to how any of our repos fare against the standard dictionaries

Add action to run R CMD Check on multiple OSs and releases of R

Github limits comments to 65536 characters, so long histories will be truncated

See example: https://github.com/RMI-PACTA/workflow.transition.monitor/actions/runs/8247752863/job/22557151977#step:10:108

Followup to #56

We've previously had an action that added a comment to the PR thread with the docker image name, with a copiable docker pull command to make life easy.

Code for that here:

  add_comment:
    needs: build-docker-image
    runs-on: ubuntu-latest
    steps:
      - name: Find Comment
        # https://github.com/peter-evans/find-comment
        uses: peter-evans/find-comment@v3
        id: fc
        with:
          issue-number: ${{ github.event.pull_request.number }}
          comment-author: 'github-actions[bot]'
          body-includes: Docker image from this PR

      - name: Create or update comment
        # https://github.com/peter-evans/create-or-update-comment
        uses: peter-evans/create-or-update-comment@v4
        with:
          comment-id: ${{ steps.fc.outputs.comment-id }}
          issue-number: ${{ github.event.pull_request.number }}
          body: |
            Docker image from this PR (${{ github.event.pull_request.head.sha }}) created
            ```
            docker pull ${{ needs.build-docker-image.outputs.full-image-name }}
            ```
          edit-mode: replace

Probably mostly of interest for report templates, but seems amenable to running in GH-actions. https://ropensci.org/blog/2024/01/16/deepl-update-babeldown/

General idea:

1. Checkout repo
2. identify changed files
3. DeepL them
4. open PR to branch with translated files
   a. If needed manually edit translations on PR branch

hadolint is a linter for dockerfiles

Make sure that when we merge a new branch, the version (dev version)? is higher than what is currently on main.

Discovered as part of RMI-PACTA/pacta.multi.loanbook.plot#16

Some R packages (igraph for example) actively discourage building from source as an alternative to using binaries.

Since CRAN only supports the past few releases of R, having old versions of R in our R CMD check matrix won't work for repos that have those packages as dependencies.

Suggested fix: make a pass through argument specifying the matrix to be used for testing with R CMD CHECK.

cc @jacobvjk

This should likely be on a voluntary or flagged basis, per repo (e.g. we decide which repos we want to auto-populate ADO tickets).

https://learn.microsoft.com/en-us/azure/devops/release-notes/2020/sprint-167-update#sync-github-issues-to-azure-devops-work-items

https://github.com/marketplace/actions/github-issues-to-azure-devops

https://github.com/danhellem/github-actions-issue-to-work-item

covr is a code coverage analysis package for R, and integrates with codecov.io

It is possible to ask GitHub to run common commands like roxygen2::roxygenise() to document a package, or styler::style_pkg() directly from GitHub. It will then commit the results to the PR. You do so by typing \style or \document as a comment on the GH PR.

I know @cjyetman doesn't particularly like things that make commits for him, but these are entirely opt-in (meaning people that want to use them can use them, and people that don't don't need to).

See here: https://github.com/RMI-PACTA/r2dii.data/blob/main/.github/workflows/pr-commands.yaml

lintr is a code linter for R language, and is incredibly useful

Check that exported functions have documentation (arguments and return value documented)

Include calling workflow, example workflow yaml, and update README for checks and actions that should run on all repos, regardless of content.

For R packages that use a Rmd README, if often happens that the Rmd is modified, but not rendered. We have an action that does this, but I'm not sure if it works perfectly, e.g. https://github.com/RMI-PACTA/pacta.portfolio.allocate/blob/main/.github/workflows/render-readme.yml

In particular, I think that (in pseudo-code) we want something like:

if (version == "X.Y.Z") 
   header(NEWS.md) contains "X.Y.Z"
else if (version == "X.Y.Z.9...")
   header(NEWS.md) contains "development version"

In the wild this looks like:
r2dii.analysis v0.3.0.9000: https://github.com/RMI-PACTA/r2dii.analysis/blob/6d0aa8df211ab2ac9d6fa6af3daf73ba2ce4e507/NEWS.md

r2dii.analysis v0.4.0: https://github.com/RMI-PACTA/r2dii.analysis/blob/8391b83325a1657ca4861387ee84c1654959a101/NEWS.md

Weekly housekeeping actions:

• https://github.com/andrewsomething/github-download-stats
• Checking branch rulesets

using pak::sysreqs_check_installed(), we can assess if the Dockerfile includes all required system dependencies for installed R packages (on supported systems, such as debian).

Include calling workflow, example workflow yaml, and update README for docker related checks and actions.

See here: https://www.youtube.com/shorts/G2uaZROAWx0

I think a weekly run would suffice tbh

Allow specifying registries other than ghcr.io for docker build action.

Version 4 has been available for around 4 years now. I'm not sure how long we want to offer support.
Probably dangerous, and user-facing but we should at least discuss it.

We already skip a lot of tests on anything older than 4, which may give us fall security into thinking that things "work"

Check that files are UTF-8 or ASCII

CRLF is for evil people.

Include calling workflow, example workflow yaml, and update README for checks and actions that are related to housekeeping and repo maintenance

ensure that everyone in the GH repo history is appropriately marked as contributing.

the docker build action should allow an input specifying which platforms to build for.

The workflow input must be an array, but that is not a supported type for inputs, so coercing a string seems the most likely option.

strategy:
      matrix:
        product: ${{ fromJSON(github.event.inputs.products)}}

See https://stackoverflow.com/q/69781005

I'm thinking that the CODEOWNERS for this repo (who would be tagged on all PRs) should maybe be @RMI-PACTA/developers, but maybe we want to have that on README (which should be updated for all new workflows), but specify individuals for certain files (for example, any non-breaking changes to the docker-* workflows are probably of interest to a few of us, but not everyone)

TBD what this exactly looks like (and likely depends on some demo data to be able to not only build but also test run our Docker builds), but it would be cool to know if a PR significantly affects the existing performance

In the absence of enforcing rules org-wide (which requires GitHub enterprise), I'd like to add a rule that checks if a repo has appropriate branch protections

Interrogating the current rules appears to be available via: https://docs.github.com/en/rest/repos/rules?apiVersion=2022-11-28

Include calling workflow, example workflow yaml, and update README for R language related checks.

might be good/advantageous to include that in some of the Actions here

https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/

• alex: https://github.com/get-alex/alex
• write-good: https://github.com/btford/write-good
• proselint

Just an FYI, two 3rd party actions that I've been using in various actions have just been updated (in case you copy them in here)

peter-evans/create-or-update-comment from v3 to v4
peter-evans/find-comment from v2 to v3

I might be the only one that uses it, but I have a board that is meant to track all issues and PRs related to Transition Monitor across many repos. It's only really feasible because I setup GH actions in each relevant repo to automatically add any newly created issues or PRs, like this https://github.com/RMI-PACTA/pacta.portfolio.allocate/blob/main/.github/workflows/add-prs-and-issues-to-project.yml

Use existing workflow to check coverage and comment in PR. Useful in case codecov is down, or we just want a quick check.

          NB: Could be cool to have an action that checks for this? (not an auto-commit, but just a notification)

Originally posted by @jdhoffa in RMI-PACTA/pacta.portfolio.import#72 (comment)

Snyk can analyze container for known vulnerabilites.

https://docs.snyk.io/scan-using-snyk/snyk-container

And maybe even as a default action?

cc: @cjyetman

Relates to https://github.com/RMI-PACTA/demo_actions/blob/main/.github/workflows/R-CMD-check.yml

We may want to decide which and how many versions of R, operating systems, etc. we want to check against.

Relates to #13

It would be good to define the oldest version of packages that are usable for our purposes.

rough logic I'm thinking of:

probably doesn't need to be run every time, but ocassionally

dependencies <- pak::local_deps()
for (dep in dependencies) {
  # find oldest version available that meets our DESCRIPTION
  # install that version
}
devtools::test()

Then updating DESCRIPTION to find a version that does pass tests would probably be a manual change.