puppetlabs / puppetlabs/cat-github-actions

gem CI workflow: Check if the gem builds

Open
#100 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
Shell
Stars
1
Forks
5
Avg merge
16m
Merged PRs (30d)
2

Description

Use Case

It makes sense to check if a gem still builds within a PR. That ensures that an upcoming release isn't broken. At Vox Pupuli we use the following matrix:

jobs:
  rubocop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Ruby ${{ matrix.ruby }}
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3"
          bundler-cache: true
      - name: Run Rubocop
        run: bundle exec rake rubocop
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        ruby:
          - "2.7"
          - "3.0"
          - "3.1"
          - "3.2"
          - "3.3"
    name: Ruby ${{ matrix.ruby }}
    steps:
      - uses: actions/checkout@v4
      - name: Install Ruby ${{ matrix.ruby }}
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: ${{ matrix.ruby }}
          bundler-cache: true
      - name: Run tests
        run: bundle exec rake
      - name: Verify gem builds
        run: gem build --strict --verbose *.gemspec

Describe the Solution You Would Like

Run gem builds with gem build --strict --verbose *.gemspec during each PR. The same should be applied for releasing a gem.

Describe Alternatives You've Considered

A clear and concise description of any alternative solutions or features you've considered.

Additional Context

This can be considered as a breaking change for gems without proper dependency boundaries. In those cases the command will fail with --strict. This change shouldn't be implemented in the main branch but rather in something like a v2. See https://github.com/puppetlabs/cat-github-actions/issues/89

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Locate the existing gem CI and release GitHub Actions workflows, then review how they run the test and release commands. Add the strict verbose gem build check to the appropriate PR and release workflows, while confirming whether it belongs in a v2 workflow rather than the main branch. Done means both workflows validate gem builds without breaking the intended compatibility boundary.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, ruby
Domain
build-system, ci-cd, release
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.