-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Also test Salt config changes as an upgrade #374
Also test Salt config changes as an upgrade #374
Conversation
7c3b8fd
to
c66f555
Compare
@bors-servo r+ Thank you! |
📌 Commit c66f555 has been approved by |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
c66f555
to
075c34d
Compare
@bors-servo r+ |
📌 Commit 075c34d has been approved by |
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 |
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 -->
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 -->
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 -->
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