Also test Salt config changes as an upgrade #374
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aneeshusa
force-pushed
the
test-upgradeability-on-travis
branch
9 times, most recently
from
7c3b8fd
to
c66f555
Compare
|
@bors-servo r+ Thank you! |
|
📌 Commit c66f555 has been approved by |
bors-servo
pushed a commit
that referenced
this pull request
Jun 2, 2016
Also test Salt config changes as an upgrade The current testing always starts from scratch. However, in practice we do not rebuild all our machines from scratch on every change, but instead usually incrementally upgrade them. Run the tests both from scratch, which is used whenever we stand up a new builder, and as an upgrade from the previous configuration, which is the more common case. Additionally, the Salt installation and Salt grains.items and state.show_highstate commands produce output that is useful for debugging, but is normally not necessary to view. Add special markers to the build log that fold these sections on Travis. This is especially useful with the longer build logs. Note that this doubles the number of builds run on Travis. r? @larsbergstrom @edunham <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/374) <!-- Reviewable:end -->
|
💔 Test failed - travis |
| if [ "${SALT_FROM_SCRATCH}" = "true" ]; then | ||
| run_salt 'scratch' | ||
| else | ||
| git checkout master |
There was a problem hiding this comment.
Travis doesn't seem to want you to do this; was it working in tests on your branch?
The approved way to use multiple branches seems to just be the matrix (https://docs.travis-ci.com/user/customizing-the-build/#Building-Specific-Branches), though I'm not sure if it'll meet this patch's needs.
There was a problem hiding this comment.
I'm pretty sure this was working on Travis last time I checked.
I think this is caused by Travis doing a shallow clone and running git checkout in different ways on PRs vs branches (auto); I think I can find a workaround.
There was a problem hiding this comment.
I added a git fetch line that should take care of it.
The current testing always starts from scratch. However, in practice we do not rebuild all our machines from scratch on every change, but instead usually incrementally upgrade them. Run the tests both from scratch, which is used whenever we stand up a new builder, and as an upgrade from the previous configuration, which is the more common case. Additionally, the Salt installation and Salt grains.items and state.show_highstate commands produce output that is useful for debugging, but is normally not necessary to view. Add special markers to the build log that fold these sections on Travis. This is especially useful with the longer build logs.
aneeshusa
force-pushed
the
test-upgradeability-on-travis
branch
from
c66f555
to
075c34d
Compare
|
@bors-servo r+ |
|
📌 Commit 075c34d has been approved by |
bors-servo
pushed a commit
that referenced
this pull request
Jun 6, 2016
Also test Salt config changes as an upgrade The current testing always starts from scratch. However, in practice we do not rebuild all our machines from scratch on every change, but instead usually incrementally upgrade them. Run the tests both from scratch, which is used whenever we stand up a new builder, and as an upgrade from the previous configuration, which is the more common case. Additionally, the Salt installation and Salt grains.items and state.show_highstate commands produce output that is useful for debugging, but is normally not necessary to view. Add special markers to the build log that fold these sections on Travis. This is especially useful with the longer build logs. Note that this doubles the number of builds run on Travis. r? @larsbergstrom @edunham <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/374) <!-- Reviewable:end -->
|
☀️ Test successful - travis |
This was referenced Jun 6, 2016
Merged
bors-servo
pushed a commit
that referenced
this pull request
Jun 20, 2016
Install Android build tools for cross compilation The Android build tools are required for building an APK. They are versioned separately from the SDK and do not have a version requirement - best practice is to use the latest (stable) release. After servo/servo#11406 landed, I forced an android-nightly build, which now gets further but still fails. The new failure is http://build.servo.org/builders/android-nightly/builds/60/steps/shell_1/logs/stdio, so install the build tools to fix this. Edit: relevant error for posterity: ``` BUILD FAILED /home/servo/android/sdk/current/tools/ant/build.xml:483: SDK does not have any Build Tools installed. ``` Another step for servo/servo#10339. I think this would benefit from #374 - I had a lot of errors trying to get the android tool to install the build tools where blowing away the directory fixed it. I think the --all parameter should take care of it, but I'd like to be more sure. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/388) <!-- Reviewable:end -->
bors-servo
pushed a commit
that referenced
this pull request
Jul 12, 2016
Fix Vagrantfile after #374 This is the second time I've broken it, so also add a test. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/394) <!-- Reviewable:end -->
bors-servo
pushed a commit
that referenced
this pull request
Sep 29, 2016
Use Nginx to make Buildbot logs available via CORS
Buildbot itself (neither the current version eight nor the upcoming
verison nine) does not seem to have built-in CORS support, so use Nginx
to supply CORS headers while reverse proxying.
This is only needed to download log files, so start with a very
conservative set of CORS headers. In particular:
- Only support basic CORS requests (those that don't require preflight
requests via OPTIONS). This means supporting only GET requests.
- Do not allow sending cookies or exposing any headers.
In return, whitelist all domains for CORS, and send the Allow-Origin
header unconditionally, as the actual value of the Origin header does
not matter.
Because we are using proxy_pass to reverse proxy Buildbot, we need to
tell Nginx to always add the CORS headers, instead of only adding them
for successful responses. (I.e. add CORS headers even for 404s and other
erroneous status codes). This features is not available in the Nginx
packaged for Ubuntu Trusty, so replace it with a newer Nginx from
upstream Nginx's respositories.
Because Debian/Ubuntu modify the default configuration for Nginx, use
Salt to ensure that the installed nginx.conf properly looks into the
sites-enabled directory (which is a Debian-ism) and that the default
handler in /etc/nginx/conf.d/ is purged.
In order to only support CORS on GET requests, use the 'if' directive.
However, because Nginx's if is evil,
(https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/)
add a bunch of tests to ensure that the configuration is working.
Also, update the Nginx states to follow Salt best practices.
Fixes #354. Blocked on #374 because I encountered various failures
while upgrading from the Ubuntu Nginx to upstream Nginx, and I'd
like to make sure I caught them all.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/375)
<!-- Reviewable:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current testing always starts from scratch.
However, in practice we do not rebuild all our machines from scratch
on every change, but instead usually incrementally upgrade them.
Run the tests both from scratch, which is used whenever we stand up
a new builder, and as an upgrade from the previous configuration, which
is the more common case.
Additionally, the Salt installation and Salt grains.items and
state.show_highstate commands produce output that is useful for
debugging, but is normally not necessary to view.
Add special markers to the build log that fold these sections on Travis.
This is especially useful with the longer build logs.
Note that this doubles the number of builds run on Travis.
r? @larsbergstrom @edunham
This change is