Development Workflow
Relevant source files
The following files were used as context for generating this wiki page:
The development workflow for sidekiq-unique-jobs is structured around maintaining high code quality, performance stability, and a secure, automated release cycle. The gem relies on sophisticated locking mechanisms in Redis, necessitating a rigorous testing and benchmarking regimen to ensure atomic operations and consistency across different Sidekiq versions.
Contributors follow a standard Git-based flow, starting from environment setup and local testing, moving through performance verification, and concluding with automated GitHub Actions for deployment. This workflow ensures that every change preserves the core promise of preventing duplicate jobs while maintaining the performance characteristics required for high-throughput environments.
Sources: CLAUDE.md:1-12, README.md:188-195
Local Development and Testing
Development is driven by a comprehensive RSpec suite and various code quality tools. Developers are expected to run style checks and tests against multiple Sidekiq versions using appraisal.
Essential Commands
| Category | Command | Description |
|---|---|---|
| Testing | bundle exec rspec | Runs the full test suite |
| Testing | bundle exec appraisal rspec | Runs tests across different Sidekiq versions |
| Linting | bundle exec rake rubocop | Runs the RuboCop linter |
| Quality | bundle exec rake reek | Detects code smells |
| Docs | bundle exec rake yard | Generates technical documentation |
Sources: CLAUDE.md:14-43
Test Environment Flow
The test suite utilizes Toxiproxy for network simulation and Timecop for temporal testing. Uniqueness behavior is often tested by clearing Redis and disabling Sidekiq testing helpers to simulate production-like execution.
The diagram shows the transition from basic unit testing to complex lock integration testing involving Redis Lua script validation.
Sources: spec/spec_helper.rb:14-25, CLAUDE.md:104-108
Performance Benchmarking
Performance is a critical metric for this project. Developers must use the provided benchmarking tools to ensure that optimizations or new features do not introduce regressions in lock acquisition speed or memory usage.
Benchmarking Tools
bin/benchmark: Full suite testing lock contention, concurrent locking, and digest generation.bin/compare_performance: Automated comparison between the current branch andmain.bin/benchmark_improvements: Targeted benchmarks for non-blocking acquisition and reaper optimizations.
Sources: BENCHMARKING.md:7-40
Performance Evaluation Logic
The flow illustrates how performance metrics guide the acceptance of code changes, prioritizing IPS improvements and memory reduction.
Sources: BENCHMARKING.md:74-90
Release Automation and Security
Releases are fully automated via GitHub Actions with a heavy focus on supply chain security. The process uses OpenID Connect (OIDC) for trusted publishing, eliminating the need for long-lived API keys.
Security Gates
- Tag-version gate: CI prevents publishing if the git tag does not match
SidekiqUniqueJobs::VERSION. - Gem content verification: The CI pipeline unpacks the gem to ensure no unwanted files (like specs or rake files) are included.
- Sigstore attestation: Every gem is signed with a keyless signature and logged in a public transparency log.
Sources: RELEASING.md:5-18
Automated Release Pipeline
This diagram outlines the automated sequence from the initial rake command to the secure delivery of the gem to RubyGems.org.
Sources: RELEASING.md:20-33
Summary
The sidekiq-unique-jobs development workflow integrates code quality enforcement, cross-version testing via appraisal, and rigorous performance benchmarking using custom tools. By leveraging OIDC and Sigstore for automated releases, the project maintains a high security posture while ensuring that job uniqueness logic remains performant and reliable across different environments.
Sources: CLAUDE.md:112-117, RELEASING.md:7-13