Open damienmg opened 7 years ago
jayconrod
commented
7 years ago @damienmg Is there any workaround until this mechanism is in place? I can't see the Bazel project on ci.bazel.io anymore. rules_go won't be able to test against development versions of Bazel.
damienmg
commented
7 years ago rules_go as well as all project on ci.bazel.io are automatically tested with devel version of Bazel, I don't see why it is needed. This API was more though to test stuff that are not tested on ci.bazel.io
damienmg
commented
7 years ago (and no there is no workaround for now, except the evil hack that rules_scala does)
philwo
commented
6 years ago This seems like a very good idea. I'm personally not a fan of putting more and more projects on our own CI, as it means we have to support features that are irrelevant for Bazel itself, but necessary for downstream projects (like the Sauce plug-in).
thomasvl
commented
6 years ago Looks like there is a way to pull the last successful build,
Using the bootstrap and maintenance > bazel > nightly, you get at the Last Successful Artifacts, so something like: https://ci.bazel.build/view/Bazel%20bootstrap%20and%20maintenance/job/bazel/job/nightly/lastSuccessfulBuild/artifact/node=darwin-x86_64/bazel--without-jdk-installer-darwin-x86_64.sh
jayconrod
commented
6 years ago @thomasvl We used to do something like that in rules_go for our tests in Travis CI. It's too sensitive to changes in Jenkins setup and project structure though. We eventually stopped testing against nightlies in Travis CI because we got broken too frequently.
thomasvl
commented
6 years ago Interesting, when I looked at what rules_go had, it seemed much more complex since you seemed to be trying to pull an html page and extract from it, but the link I mentioned seems like it is built to be stable. Yes, if the whole project being extract from was changed it would break, but I was hoping that wasn't something common.
jayconrod
commented
6 years ago The project structure did change: If I remember correctly, "Bazel bootstrap and maintenance" used to be something else. Also the basename of the downloaded file isn't stable. There can be version numbers between the hyphens in bazel--without-jdk-installer-darwin-x86_64.sh. I think that mostly came up when preparing release candidates.
buchgr
commented
6 years ago The proposal is to always publish the latest bazel binary that passes all tests and downstream project tests on all platforms - so ideally after every commit to Bazel :-). We have already implemented this on our new Buildkite CI, there's a JSON file that automatically gets updated after every such build: http://storage.googleapis.com/bazel-builds/metadata/latest_fully_tested.json
However, it's not live yet - we'll ping you once it is.
In order to test Bazel for regression on downstream projects at Google we need to offer an API to connect other CI to download Bazel, test it and report error. Letting the other CI poll a URL is probably enough for now.