Skip to content

Latest commit

 

History

History
84 lines (65 loc) · 5.3 KB

CONTRIBUTING.md

File metadata and controls

84 lines (65 loc) · 5.3 KB

How To Contribute To Beaker

Getting Started

Making Changes

  • Create a topic branch from where you want to base your work.
    • This is the master branch in the case of Beaker
    • To quickly create a topic branch based on master use git checkout -b my_contribution master. Please avoid working directly on the master branch.
  • Make commits of logical units.
  • Check for unnecessary whitespace with git diff --check before committing.
  • Make sure your commit messages are in the proper format.
    (BKR-1234) Make the example in CONTRIBUTING imperative and concrete

    Without this patch applied the example commit message in the CONTRIBUTING
    document is not a concrete example.  This is a problem because the
    contributor is left to imagine what the commit message should look like
    based on a description rather than an example.  This patch fixes the
    problem by making the example concrete and imperative.

    The first line is a real life imperative statement with a ticket number
    from our issue tracker.  The body describes the behavior without the patch,
    why this is a problem, and how the patch fixes the problem when applied.
  • Make sure you have added RSpec tests that exercise your new code. These test should be located in the appropriate beaker/spec/ subdirectory. The addition of new methods/classes or the addition of code paths to existing methods/classes requires additional RSpec coverage.
    • Beaker uses RSpec 3.1.0+, and you should NOT USE deprecated should/stub methods - USE expect/allow. Use of deprecated RSpec methods will result in your patch being rejected. See a nice blog post from 2013 on RSpec's new message expectation syntax.
  • Make sure that you have added documentation using Yard, new methods/classes without apporpriate documentation will be rejected.
  • Run the tests to assure nothing else was accidentally broken, using rake test
    • Bonus: if possible ensure that rake test runs without failures for additional Ruby versions (1.9, 2.0, etc). Beaker supports Ruby 1.9+, and breakage of support for older/newer rubies will cause a patch to be rejected.
  • During the time that you are working on your patch the master Beaker branch may have changed - you'll want to rebase before you submit your PR with git rebase master. A successful rebase ensures that your patch will cleanly merge into Beaker.
  • Submitted patches will be smoke tested through a series of acceptance level tests that ensures basic Beaker functionality - the results of these tests will be evaluated by a Beaker team member. Failures associated with the submitted patch will result in the patch being rejected.

Making Trivial Changes

Maintenance

We are no longer accepting PRs marked as (MAINT) - all PRs must be associated with a Beaker Jira ticket number for book keeping purposes.

Version Bump For Gem Release

To prepare for a new gem release of Beaker the version.rb file is updated with the upcoming gem version number. This is submitted with (GEM) instead of a ticket/issue number.

     (GEM) Update version for Beaker 1.16.1

History File Update

To prepare for a new gem release of Beaker (after the version has been bumped) the HISTORY.md file is updated with the latest GitHub log. This is submitted with (HISTORY) instead of a ticket/issue number.

    (HISTORY) Update history for release of Beaker 1.16.1

Submitting Changes

  • Sign the Contributor License Agreement.
  • Push your changes to a topic branch in your fork of the repository.
  • Submit a pull request to Beaker
  • Update your ticket
    • Update your Jira ticket to mark that you have submitted code and are ready for it to be considered for merge (Status: Ready for Merge).
      • Include a link to the pull request in the ticket.
  • PRs are reviewed as time permits.

Additional Resources