Name: circlemator
Owner: Rainforest QA
Description: A bucket of tricks for automating CircleCI and Github
Created: 2016-01-22 02:53:04.0
Updated: 2018-05-07 12:48:40.0
Pushed: 2018-05-07 12:54:43.0
Homepage: https://www.rainforestqa.com/
Size: 75
Language: Ruby
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Circlemator is a bucket of tricks for working with CircleCI and Github used internally at Rainforest QA.
Add this line to your application's Gemfile:
'circlemator', require: false
Then run bundle and check in the resulting Gemfile.lock. That should
be enough, really.
Circlemator tasks are designed to be added to your circle.yml file like so:
ndle exec circlemator <task> [options]
Different tasks require different options/placement in your circle.yml.
CircleCI starts a build every time you push to Github. That's usually
a good thing, but if you have a big test suite it can be annoying when
your build queue gets gummed up running builds on out-of-date
commits. To clear things up, the cancel-old task cancels all builds
that are not at the head of their branch. It should be in your
circle.yml before your tests are run but after the dependencies have
been fetched, for example:
:
e:
- bundle exec circlemator cancel-old
In order for this to work, you need the following environment variable to be set in CircleCI:
CIRCLE_API_TOKEN: Your CircleCI API token. (Can also be set with
the -t option.)You can comment on the open PR using the comment command:
:
st:
- bundle exec circlemator comment 'A totally unnecessary comment' --base-branch=develop
Think of this as a poor man's HoundCI: it runs Rubocop (and/or more linters/checkers TBD) and comments on the Github pull request using the excellent Pronto. Use it like so:
:
e:
- bundle exec circlemator style-check --base-branch=develop
(Note: use local branch names, like develop instead of
origin/develop; origin will be prepended for running pronto as
necessary.)
It probably makes sense to put style-check in either the pre or
override steps.)
style-check requires the following environment variable to be set:
GITHUB_ACCESS_TOKEN: A Github API auth token for a user with commit
access to your repo. (Can also be set with the -g option.)Preamble: at Rainforest, our process for getting code into production looks like this:
develop.develop to master.develop.develop into master if everything's green.master.Out of these, steps 1, 2, 3, and 4 require manual intervention, but
everything else should be automatic! The self-merge task is designed
to take care of step 6 (the rest is handled by CircleCI out of the
box).
To use self-merge, add something like the following to your
circle.yml:
oyment:
aging:
branch: develop
commands:
<any commands you would normally run>
- bundle exec circlemator self-merge --base-branch=master --compare-branch=develop
Swap out develop and master as necessary to fit your workflow. Be
warned, the circlemator command should probably be the last command
in your deploy stage! (Otherwise you'll merge before your build is
done.)
self-merge will only run if there is an open pull request against
the base branch. That means you have a way to prevent automatic
shipping in exceptional circumstances: just don't open a release pull
request.
self-merge requires the following environment variable to be set:
GITHUB_ACCESS_TOKEN: A Github API auth token for a user with commit
access to your repo. (Can also be set with the -g option.)Also, unfortunately branch protection cannot be enabled on your
master branch. (Contributions welcome for anyone who can think of a
workaround…)
Bug reports and pull requests are welcome on GitHub at https://github.com/rainforestapp/circlemator.
rake release