Simplify atime GHA workflow using r-lib/actions, gh, and jq

[MichaelChirico]

Gemini-authored alternative to #7901.

[github-actions]

• HEAD=new-atime-ci-ii much slower for as.data.table.array improved in #7019
• HEAD=new-atime-ci-ii much slower for isoweek improved in #7144
• HEAD=new-atime-ci-ii slower P<0.001 for fwrite refactored in #6393

Generated via commit 4c9c84f

Download link for the artifact containing the test results: ↓ atime-results.zip

Task	Duration
R setup and installing dependencies	1 minutes and 21 seconds
Installing different package versions	24 seconds
Running and plotting the test cases	5 minutes and 18 seconds

[tdhock]

these modifications do R pkg installation using r-lib actions, whereas I proposed using Dirk’s actions

    - name: Setup
      uses: eddelbuettel/github-actions/r-ci@master
    - name: Dependencies
      run: ./run.sh install_all

[MichaelChirico]

Yea, I intentionally let it switch back to r-lib/actions based on this finding:

Using eddelbuettel/github-actions/r-ci@master here introduces a second R setup stack, leaves untracked ./run.sh and .Rprofile files in GITHUB_WORKSPACE (which atime copies into every historical build directory), and writing options(repos = c(CRAN = 'https://cloud.r-project.org')) to .Rprofile bypasses binary repositories so atime, ggplot2, and directlabels compile from source.

Those drawbacks can be overcome, but would you mind elaborating on why you think the r-ci GHA is a better choice for us? I also am persuaded against it because it leaves us in a split state of r-lib/actions in all the other GHA and only the new approach in this particular action -- should we make a full switch?

Also, is there a reason to use @master instead of a pinned version?

[tdhock]

@MichaelChirico do you mind switching to Dirk’s r-ci? I seemed to recall Dirk mentioning it was much faster than r-lib but I don’t actually have any data on that.

[MichaelChirico]

I suspect the caching here is good enough -- I'm seeing 7m for the {atime} runs on this branch

If we want to move to r-ci, I would recommend doing so across all our GHA as a separate issue.

[aitap]

We could use native GitHub image uploads for comments with gh pr comment --attach, but that requires --edit-last --create-if-none (edit last comment by GitHub Actions or create if none exist so far). There doesn't seem to be a way to edit a specific comment in gh pr comment while also making use of --attach.

[tdhock]

thanks Ivan, this is very useful!
I did not know that --attach API was documented, that is great!! (last time I checked I could not find a public API for that, is it new?)
a work-around would be deleting the previous comment and creating a new one?

[aitap]

Sorry, no, --attach doesn't work yet because it's broken for GHA tokens.

[MichaelChirico]

Great spot on --edit-last --create-if-none, included in 4c9c84f.

LLM report on --attach:

---

On --attach: gh pr comment actually supports rewriting local Markdown image/link targets in-place with --edit-last --create-if-none (so [![Comparison Plot](.ci/atime/tests_preview_facet.png)](.ci/atime/tests_all_facet.png) works), but gh's attachment uploader (internal/attachments/client.go) explicitly rejects ghs_ server-to-server tokens (GITHUB_TOKEN) with "unsupported authentication type" because uploads.github.com/user-attachments/assets requires a user-attributed token (ghp_ / github_pat_ / gho_ / ghu_) and contents: write permission. So unless we want to maintain a user PAT secret, we still need picrd.com for image hosting.

---

There's a way forward if we set up a bot account like @rdatatable-bot but it would have to have pretty broad access grants (Pull requests: Write won't suffice).

[tdhock]

thanks for the suggestions, I agree that using gh is better than curl/sed/etc