Contributing

Bug reports and pull requests are welcome on GitHub, CodeBerg, or GitLab.
This project should be a safe, welcoming space for collaboration, so contributors agree to adhere to
the code of conduct.

To submit a patch, please fork the project, create a patch with tests, and send a pull request.

Remember to Keep A Changelog.

Help out!

Take a look at the reek list which is the file called REEK and find something to improve.

Follow these instructions:

  1. Fork the repository
  2. Create a feature branch (git checkout -b my-new-feature)
  3. Make some fixes.
  4. Commit changes (git commit -am 'Added some feature')
  5. Push to the branch (git push origin my-new-feature)
  6. Make sure to add tests for it. This is important, so it doesn’t break in a future release.
  7. Create new Pull Request.

Appraisals

From time to time the Appraisal2 gemfiles in gemfiles/ will need to be updated.
They are created and updated with the commands:

BUNDLE_GEMFILE=Appraisal.root.gemfile bundle
BUNDLE_GEMFILE=Appraisal.root.gemfile bundle exec appraisal update
bundle exec rake rubocop_gradual:autocorrect

When adding an appraisal to CI check the runner tool cache to see which runner to use.

The Reek List

Take a look at the reek list which is the file called REEK and find something to improve.

To refresh the reek list:

bundle exec reek > REEK

Run Tests

To run all tests

bundle exec rake test

Test hygiene and coverage notes:

  • Sentinel lockfiles are ephemeral. The test harness removes any .floss_funding.*.lock files in the project root before the suite starts and again after it finishes. If you run specs outside the standard harness, make sure to delete these files to avoid stale at-exit/on-load state affecting results.
  • Coverage output is always printed when coverage is enabled, even if specs fail. Do not interpret a coverage report as success; always check RSpec’s exit status and failure summary.
  • When running only a subset of specs locally, you may need to disable the hard coverage threshold with K_SOUP_COV_MIN_HARD=false as documented in the project guidelines.

Lint It

Run all the default tasks, which includes running the gradually autocorrecting linter, rubocop-gradual.

bundle exec rake

Or just run the linter.

bundle exec rake rubocop_gradual:autocorrect

For more detailed information about using RuboCop in this project, please see the RUBOCOP.md guide. This project uses rubocop_gradual instead of vanilla RuboCop, which requires specific commands for checking violations.

Important: Do not add inline RuboCop disables

Never add # rubocop:disable ... / # rubocop:enable ... comments to code or specs (except when following the few existing rubocop:disable patterns for a rule already being disabled elsewhere in the code). Instead:

  • Prefer configuration-based exclusions when a rule should not apply to certain paths or files (e.g., via .rubocop.yml).
  • When a violation is temporary and you plan to fix it later, record it in .rubocop_gradual.lock using the gradual workflow:
    • bundle exec rake rubocop_gradual:autocorrect (preferred)
    • bundle exec rake rubocop_gradual:force_update (only when you cannot fix the violations immediately)

As a general rule, fix style issues rather than ignoring them. For example, our specs should follow RSpec conventions like using described_class for the class under test.

Contributors

Your picture could be here!

Contributors

Made with contributors-img.

Also see GitLab Contributors: https://gitlab.com/galtzo-floss/floss_funding/-/graphs/main

For Maintainers

One-time, Per-maintainer, Setup

IMPORTANT: If you want to sign the build you create,
your public key for signing gems will need to be picked up by the line in the
gemspec defining the spec.cert_chain (check the relevant ENV variables there).
All releases to RubyGems.org will be signed.
See: RubyGems Security Guide

NOTE: To build without signing the gem you must set SKIP_GEM_SIGNING to some value in your environment.

To release a new version:

  1. Run bin/setup && bin/rake as a “test, coverage, & linting” sanity check
  2. Update the version number in version.rb, and ensure CHANGELOG.md reflects changes
  3. Run bin/setup && bin/rake again as a secondary check, and to update Gemfile.lock
  4. Run git commit -am "🔖 Prepare release v<VERSION>" to commit the changes
  5. Run git push to trigger the final CI pipeline before release, and merge PRs
  6. Run export GIT_TRUNK_BRANCH_NAME="$(git remote show origin | grep 'HEAD branch' | cut -d ' ' -f5)" && echo $GIT_TRUNK_BRANCH_NAME
  7. Run git checkout $GIT_TRUNK_BRANCH_NAME
  8. Run git pull origin $GIT_TRUNK_BRANCH_NAME to ensure latest trunk code
  9. Set SOURCE_DATE_EPOCH so rake build and rake release use same timestamp, and generate same checksums
    • Run export SOURCE_DATE_EPOCH=$EPOCHSECONDS && echo $SOURCE_DATE_EPOCH
    • If the echo above has no output, then it didn’t work.
    • Note: zsh/datetime module is needed, if running zsh.
    • In older versions of bash you can use date +%s instead, i.e. export SOURCE_DATE_EPOCH=$(date +%s) && echo $SOURCE_DATE_EPOCH
  10. Run bundle exec rake build
  11. Run bin/gem_checksums (more context 1, 2)
    to create SHA-256 and SHA-512 checksums. This functionality is provided by the stone_checksums
    gem.
    • The script automatically commits but does not push the checksums
  12. Run bundle exec rake release which will create a git tag for the version,
    push git commits and tags, and push the .gem file to rubygems.org