puppetlabs / puppetlabs/cat-github-actions
gem CI workflow: Check if the gem builds
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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