7 Continuous Integration

7.1 Understanding GitHub Actions

GitHub Actions is GitHub’s built-in automation platform that makes it easy to automate software workflows, including continuous integration and deployment (CI/CD). For R packages, this means you can automatically test your code, check for errors, and deploy documentation every time you push changes to GitHub.

Key benefits of GitHub Actions:

Automated testing: Run R CMD check across multiple operating systems (Linux, macOS, Windows) and R versions
Immediate feedback: Get notified of problems quickly, when they’re easier to fix
Better collaboration: External contributors can see if their changes pass all checks before you review
Quality assurance: Catch platform-specific issues before they reach users
Documentation deployment: Automatically build and deploy your pkgdown website

Even for solo developers, having automated checks run on different platforms helps avoid the “works on my machine” problem.

7.2 Setting Up GitHub Actions

The easiest way to add GitHub Actions to your R package is using {usethis}. The tidyverse team maintains a collection of ready-to-use workflows at r-lib/actions that handle common R package tasks.

7.2.1 Essential Workflows

1. R CMD check (most important):

usethis::use_github_action("check-standard")

This runs R CMD check on Linux, macOS, and Windows to ensure your package works across platforms. If you only set up one workflow, make it this one.

2. Test coverage:

usethis::use_github_action("test-coverage")

Calculates what percentage of your code is covered by tests and reports to codecov.io.

3. Package website:

usethis::use_github_action("pkgdown")

Automatically builds and deploys your pkgdown documentation site to GitHub Pages.

7.2.2 Interactive Setup

Running usethis::use_github_action() without arguments shows a menu of recommended workflows:

usethis::use_github_action()
#> Which action do you want to add? (0 to exit)
#> (See <https://github.com/r-lib/actions/tree/v2/examples> for other options)
#>
#> 1: check-standard: Run `R CMD check` on Linux, macOS, and Windows
#> 2: test-coverage: Compute test coverage and report to https://about.codecov.io
#> 3: pr-commands: Add /document and /style commands for pull requests

7.3 How GitHub Actions Workflows Work

When you set up a workflow, usethis creates a YAML configuration file in .github/workflows/. For example, check-standard creates .github/workflows/R-CMD-check.yaml.

This workflow automatically runs when you:

Push commits to main or master
Open or update a pull request

You can view workflow results in the “Actions” tab of your GitHub repository. A status badge is added to your README showing whether checks are passing.

7.4 Workflow Files and Security

Warning

Important Security Consideration

Workflow files (.github/workflows/*.yaml) have access to repository secrets and can execute code. Always review workflow files carefully before committing them, especially if copied from external sources.

See Section 18.5.8 for guidance on working with workflow files using AI tools.

The workflow YAML files in .github/workflows/ are configuration files that tell GitHub Actions:

When to run (on push, pull request, schedule, etc.)
What operating systems and R versions to use
What steps to execute (install dependencies, run checks, etc.)

7.5 Troubleshooting Failed Workflows

When workflows fail, check the “Actions” tab in your GitHub repository for detailed logs. Common issues include:

Test failures: Your tests found a bug (this is good! fix the bug)
Platform-specific issues: Code works on your machine but not on other platforms
Missing dependencies: System libraries needed for packages aren’t installed
Linting errors: Code style issues detected by automated checks

For help addressing workflow failures, see Section 18.5.6.

7.6 Pull Request Comment Automation

GitHub Actions can automatically comment on pull requests to provide feedback, status updates, or deployment previews. This section compares commonly used actions for managing PR comments, helping you choose the right tool for your workflow.

7.6.0.1 Common Use Cases

PR comment automation is particularly useful for:

CI/CD status updates: Report test results, build status, or deployment progress
Code quality reports: Post coverage reports, linting results, or security scan findings
Deployment previews: Share links to preview deployments (e.g., documentation sites, app previews)
Bot feedback: Provide automated feedback without cluttering the PR conversation

7.6.0.2 Comparison of Popular Actions

marocchino/sticky-pull-request-comment

A widely-used action for creating or updating a single comment per workflow (as of early 2026, ~580 GitHub stars). Prevents comment spam by updating the same comment each time the workflow runs.

Key features:

Sticky comments: Creates or updates a comment identified by a unique header
Multiple independent comments: Different workflows can maintain separate sticky comments using different headers
Flexible update modes: Replace, append, recreate, delete, or hide comments
File-based messages: Load comment content from files for complex templates
Works with push events: Can find and comment on PRs from push triggers (useful for monorepos)

Typical usage:

- uses: marocchino/sticky-pull-request-comment@v2
  with:
    header: test-results
    message: |
      ## Test Results
      ```
      ${{ steps.test.outputs.summary }}
      ```

Best for: Projects needing clean, updatable status comments without duplicates. Ideal when you want the same type of information always visible in one place.

hasura/comment-progress

Designed for tracking workflow progress with multiple updates as jobs complete. Similar to how Netlify or SonarCloud bots provide progressive feedback.

Key features:

Progress tracking: Update comments as workflow steps complete or fail
Identifier-based updates: Uses a hidden identifier to find and update the correct comment
Multiple update modes: Append to existing comments, recreate, or delete
Flexible targets: Comment on PRs, issues, or specific commits
Failure handling: Optionally fail the workflow and append failure messages

Typical usage:

- uses: hasura/comment-progress@v2.3.0
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    repository: ${{ github.repository }}
    number: ${{ github.event.number }}
    id: deploy-progress
    message: "Deploy in progress..."
    append: true

Best for: Long-running workflows where you want to provide incremental status updates as different stages complete. Good for deployment pipelines or multi-stage builds.

thollander/actions-comment-pull-request

A simpler, more straightforward action for posting or updating PR comments. Good balance of features and ease of use.

Key features:

Simple comment creation: Easy to post one-time or updated comments
Comment updates: Find and update existing comments by ID or content
Reactions: Add emoji reactions to comments
Comment deletion: Remove comments when no longer needed
Dynamic content: Supports multi-line messages and environment variables

Typical usage:

- uses: thollander/actions-comment-pull-request@v2
  with:
    message: |
      ## Deployment Status
      ✅ Successfully deployed to preview environment
      Preview URL: https://preview-${{ github.event.number }}.example.com

Best for: Straightforward commenting needs without complex update logic. Good for simple status messages or one-time notifications.

rossjrw/pr-preview-action

Specialized action for deploying pull request previews to GitHub Pages. Unlike the general-purpose comment actions above, this action handles the complete preview deployment lifecycle: building previews, deploying them to a GitHub Pages branch, and posting a comment with the preview link.

Key features:

Automated preview deployment: Creates and deploys PR previews to a GitHub Pages branch (e.g., gh-pages)
Preview URLs: Generates predictable preview URLs like https://[owner].github.io/[repo]/pr-preview/pr-[number]/
Sticky comments with links: Posts and updates a comment with the preview URL and optional QR code for mobile access
Automatic cleanup: Removes preview deployments when PRs are closed
Selective cleanup: Can be configured to only remove previews for unmerged PRs, preserving merged PR previews for historical reference
Compatibility safeguards: Designed to coexist with main branch deployments without conflicts

Typical usage:

- uses: rossjrw/pr-preview-action@v1
  with:
    source-dir: ./docs/
    preview-branch: gh-pages
    umbrella-dir: pr-preview

Advanced usage - only remove unmerged PR previews:

# Deploy preview when PR is opened/updated
- uses: rossjrw/pr-preview-action@v1
  if: contains(['opened', 'reopened', 'synchronize'], github.event.action)
  with:
    source-dir: ./docs/
    action: deploy

# Remove preview only for unmerged PRs
- uses: rossjrw/pr-preview-action@v1
  if: github.event.action == "closed" && !github.event.pull_request.merged
  with:
    source-dir: ./docs/
    action: remove

This selective cleanup pattern (from the pr-preview-action documentation) is particularly useful when you want to:

Keep a historical record of what each merged PR changed
Allow stakeholders to review merged changes after the fact
Maintain preview URLs referenced in issue discussions or documentation

Best for: Projects using GitHub Pages for documentation, web apps, or other static sites where stakeholders benefit from previewing changes before merging. Essential when you want reviewers to see the rendered output (e.g., documentation sites, UI changes) rather than just the source code.

7.6.0.3 Feature Comparison

Comparison of PR comment action features
Feature	marocchino/sticky	hasura/comment-progress	thollander/actions-comment	rossjrw/pr-preview
Update existing comment	✅ (by header)	✅ (by identifier)	✅ (by ID or content)	✅ (automatic)
Multiple independent comments	✅ (via headers)	✅ (via identifiers)	⚠️ (limited)	❌ (single preview link)
Append mode	✅	✅	❌	❌
Delete comments	✅	✅	✅	✅ (on PR close)
Hide comments	✅	❌	❌	❌
File-based messages	✅	❌	❌	❌
Emoji reactions	❌	❌	✅	❌
Works with push events	✅	⚠️ (requires PR number)	⚠️ (requires PR number)	⚠️ (requires PR number)
Progress tracking focus	⚠️ (flexible)	✅	❌	❌
Deploy to GitHub Pages	❌	❌	❌	✅
QR code generation	❌	❌	❌	✅ (optional)
Selective cleanup	❌	❌	❌	✅ (merged vs unmerged)

7.6.0.4 Choosing the Right Action

Use marocchino/sticky-pull-request-comment when:

You need to maintain multiple independent status comments (test results, coverage, deployment, etc.)
You want to prevent comment spam by updating the same comment
You need advanced features like hiding outdated comments or file-based templates
Your workflow triggers on push events and needs to find the associated PR

Use hasura/comment-progress when:

You have long-running workflows with multiple stages
You want to provide progressive feedback as each stage completes
You need the workflow to fail and report the failure in the comment
You want a pattern similar to third-party CI/CD service bots

Use thollander/actions-comment-pull-request when:

You need simple comment posting without complex update logic
You want to add emoji reactions to comments
You’re comfortable with the action’s simpler update mechanism
Your use case doesn’t require the advanced features of the other options

Use rossjrw/pr-preview-action when:

You need to deploy preview versions of your site/app to GitHub Pages for each PR
You want stakeholders to review rendered output (documentation, UI) rather than just code
You need automatic cleanup of preview deployments when PRs close
You want to preserve previews of merged PRs for historical reference
Your project uses GitHub Pages and benefits from preview environments

7.6.0.5 Security Considerations

Warning

Important: PR Comment Permissions

PR comment actions require write access to pull requests, which means they need the pull-requests: write permission.

For workflows triggered by pull requests from forks (common in open-source projects), be careful about what information you expose in comments, as fork contributors can trigger these workflows. Never expose secrets or sensitive information in PR comments.

See Section 18.5.8 for more guidance on workflow security.

7.7 Additional Resources

GitHub Actions features overview
r-lib/actions repository - R-specific actions and example workflows
R Packages book: Continuous Integration
GitHub Actions documentation
Where to find help with r-lib/actions