Add integration for CircleCI.
Review Request #8951 — Created May 19, 2017 and submitted
This change adds a new integration which allows people to build prospective
changes via CircleCI. This requires the (beta) CircleCI 2.0.This is similar in many ways to the Travis CI integration, but is somewhat
different in its configuration. The major difference is that while Travis
allows us to override the config within our API request, Circle does not. This
means that users will have to add Review Board support within their
.circleci/config.yml
file.When a config matches, this integration will trigger a build of the
"reviewboard" job (as defined in the user's config) and pass along various bits
of data in the build parameters.
Posted a variety of changes which should either fail or pass the build, and
saw the results reported correctly.
Description | From | Last Updated |
---|---|---|
E251 unexpected spaces around keyword / parameter equals |
reviewbot | |
E251 unexpected spaces around keyword / parameter equals |
reviewbot | |
E501 line too long (82 > 79 characters) |
reviewbot | |
E999 SyntaxError: invalid syntax |
reviewbot | |
F841 local variable 'config' is assigned to but never used |
reviewbot | |
reviewboard.reviews.models.review_request.ReviewRequest. It won't link otherwise. You can break the line at the . now though. |
chipx86 | |
Does CircleCI support GitHub Enterprise? |
chipx86 | |
Why not put this in the argument list? |
chipx86 | |
Since the user could in theory have multiple tokens, we should probably handle that case here so things don't break. |
chipx86 | |
urlquote_plus will fail if circle_api_token is None (missing in config). |
chipx86 | |
Do we need to send this? Seems the Local Site + display ID would be enough. I'd rather not expose … |
chipx86 | |
How does this user work when using Local Sites? |
chipx86 | |
There's potential for a race condition here, where in-between the previous lookup and now another thread created this user. We … |
chipx86 | |
Blank line before the comment. |
chipx86 | |
We need unit tests handling Local Site scenarios. |
chipx86 | |
*args |
chipx86 | |
**kwargs |
chipx86 | |
Let's dump the payload so we have something to go off of for debugging. |
chipx86 | |
As above, it would be nice to use the display ID + Local Site name, instead of passing around the … |
chipx86 | |
Display ID + Local Site name |
chipx86 | |
Missing period. |
chipx86 | |
We're still exposing the review request ID. We should be purely using the display ID + local site, and never … |
chipx86 | |
Why _response? Not _Response? |
chipx86 | |
Having all the content on one line will help tie things together in the logs, since otherwise entries can become … |
chipx86 |
- Commit:
-
309cf6424e1a766f1d9d81a64215aa26729b121d169f7dff8dbcd9645e183533b3ae006cbff98c41
- Diff:
-
Revision 2 (+447 -41)
Checks run (2 succeeded)
- Change Summary:
-
Add tests for basic behavior. This requires fewer tests than Travis right now because the config on the RB side is quite a bit simpler.
- Description:
-
This change adds a new integration which allows people to build prospective
changes via CircleCI. This requires the (beta) CircleCI 2.0. This is similar in many ways to the Travis CI integration, but is somewhat
different in its configuration. The major difference is that while Travis allows us to override the config within our API request, Circle does not. This means that users will have to add Review Board support within their .circleci/config.yml
file.When a config matches, this integration will trigger a build of the
"reviewboard" job (as defined in the user's config) and pass along various bits of data in the build parameters. - - Documentation and unit tests will be forthcoming in a future change.
- Commit:
-
169f7dff8dbcd9645e183533b3ae006cbff98c410436b0ed49484262b222af443b8d935447a50e8a
- Diff:
-
Revision 3 (+596 -41)
- Commit:
-
0436b0ed49484262b222af443b8d935447a50e8aba0dbcb867a15501384e391a60b26e30f70410ed
- Diff:
-
Revision 4 (+596 -41)
Checks run (2 succeeded)
-
-
reviewboard.reviews.models.review_request.ReviewRequest
. It won't link otherwise. You can break the line at the.
now though. -
-
-
Since the user could in theory have multiple tokens, we should probably handle that case here so things don't break.
-
-
Do we need to send this? Seems the Local Site + display ID would be enough. I'd rather not expose this if we can avoid it.
-
-
There's potential for a race condition here, where in-between the previous lookup and now another thread created this user. We should have a
try/except
around this and return the existing entry if we get anIntegrityError
. -
-
-
-
-
-
As above, it would be nice to use the display ID + Local Site name, instead of passing around the database ID.
-
- Commit:
-
ba0dbcb867a15501384e391a60b26e30f70410eddfc94e5f7092211345a3326fbdbe638f7474a63c
- Diff:
-
Revision 5 (+666 -41)
Checks run (2 succeeded)
- Commit:
-
dfc94e5f7092211345a3326fbdbe638f7474a63c92bed8091386e0d95bdfc9a74d7fd21fba67d095
- Diff:
-
Revision 6 (+666 -41)