Package only changes don't trigger build or unit tests#5180
Package only changes don't trigger build or unit tests#5180alalazo wants to merge 3 commits intospack:developfrom
Conversation
This modifies Travis configuration so that PRs with package only changes don't trigger unit-tests or build-tests, but they fake a success instead (there still seem to be no way to skip a stage in Travis). Consequently, coverage report is not submitted and will not be displayed
|
@tgamblin @adamjstewart I think what is in this PR (modulo bugs) is the best we can do with the current Travis. Above I commented a couple of lines in a script, to fake the behavior of a PR with package only changes, and the result is only partially satisfying: we can't avoid starting a job, and just preparing the environment takes a couple of minutes. What's worse is that we can't avoid waiting for an OSX worker to be ready which can take easily half an hour. If I did things correctly, when Travis will finish, I should have no coverage report - just a green tick. As soon as I uncomment the two lines in the script things should go back to normal behavior: as here I am clearly modifying core it should run everything and submit coverage. |
alalazo
force-pushed
the
qa/skip_unit_tests_and_builds_on_packages
branch
from
51b4562 to
f3bd811
Compare
alalazo
added
ready
tests
|
@tgamblin @adamjstewart To help you have an idea: in 3e822e2 I faked being a PR with package only modifications. You can click on the green tick near the first commit above to see the reduction in time, and the absence of coverage report. |
|
Closing as superseded by #5842 |
1 participant
This changeset modifies Travis configuration so that PRs with package only changes don't trigger unit-tests or build-tests, but they will exit early and fake a success instead. Consequently, coverage report is not submitted and will not be displayed for them. The time to execute a fake test is that of setting up the environment and varies approximately between 1-2 minutes (instead of ~10 minutes of most real tests).
A preferable alternative would be to skip these stages entirely, but that seems not possible right now.. The major problem we still cannot get rid of is that we need in any case to wait for an OSX executor to become available - and that may mean a waiting time of even half an hour to get scheduled.