I don’t see how to perform extra tests when building a pull request, but not when building an arbitrary branch.
Suppose that I have a branch, and CircleCI is testing that branch.
The CIRCLE_COMPARE_URL environment is not set on those CircleCI jobs.
(With Travis 2.1 it is necessary to use the iynere/compare-url Orb, but the same principle applies.)
Now, I make a pull request from the branch.
CircleCI doesn’t run again, because the code is the same as was tested previously on the branch.
Therefore, any special handling of branches is not triggered.
Can you suggest how to accomplish my goal, of running code for each pull request?
Can you help me understand what the extra tests would look like. Are these separate tests than the ones that already ran as a part of the original commit?
As one example, consider the policy that, in a pull request, every new or changed line satisfies some style guideline. That is a way to incrementally bring a legacy project into conformance with a new style guideline.
There is no way for a branch test to enforce such a guideline, because there is no way to know what upstream the branch will be pull-requested into.
Section “Incremental use” in the following shows how to enforce that new/changed Java methods should contain Javadoc comments:
Bumping this because I also need this workflow. One of my projects has a series of heavy tests that we do not want to run as part of the every commit light-weight tests. We only want to run them when a PR has been opened.
Right now, the only way i’m getting around this is to move all of those tests to a “run” step and test for $CIRCLE_PULL_REQUEST - this isn’t ideal though as it still has to spin up the job in order to test if its a PR or not.
I could add that conditional to the regular commit level tests and have it filter there, but then i lose the ability to run it in parallel to the other tests.