Need to migrate from Travis CI to another provider

[acmcarther]

Due to some touch-and-go permissions-related stuff[1] with Travis CI migrating travis-ci.org usages from the org domain to the com domain, this project needs to prepare a migration to an alternative CI provider.

BuildKite is probably the best contender, since we already have it for rules_rust. That's running under organization bazelbuild though, so there might be some work involved. Some other alternatives are GitHub Actions and CircleCI.

(heads up for you @UebelAndre)

---

Deadline on this is Dec 31st 2020[1]

[1] Travis folks are currently requiring repo scope in the Oauth token grant for users migrating to the .com instance. This is prohibited by a Google organization policy. [2] https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-when-will-the-migration-from-travis-ciorg-to-travis-cicom-be-completed

[acmcarther]

CI might get flaky in the lead up to the 31st both because I'll be messing with it and also because the Travis CI folks might be doing migration stuff.

[UebelAndre]

I feel like the repo is in pretty decent shape to migrate to Bazel (especially since https://github.com/google/cargo-raze/pull/300 was merged which eliminates the need for external dependencies). The smoke tests are the only mystery for me but I think I have a path forward there. I've never setup anything with BuildKite but I'd expect it to be pretty straight forward if the project is building with Bazel. But let me know if you think that's a good idea.

@acmcarther Thanks for the heads up 🙏 😄

[UebelAndre]

Though that said, I have a couple of small changes and 2 medium changes I'd like to get through. If you could review them for me I can work on a Bazel migration this weekend. I've als been really hoping for a release with workspace support 🙏

[UebelAndre]

I started on #61 over the weekend and ran into a few complications trying to build a few transitive dependencies. Probably just need another weekend on it and Bazel builds should be available in a PR.

[UebelAndre]

I think i finally got openssl to build correctly in Bazel over the weekend. I'm working on a few more crates that I might be able to get working before the end of the week. If anyone is interested in the progress. Check out https://github.com/UebelAndre/cargo-raze/tree/bazel

[UebelAndre]

@acmcarther Building with Bazel now works! There's still some issues compiling the tests (namely basic-cookie) but if I can get that working then I just need to write a test rule that checks to see examples are only the result of running cargo-raze (no user modifications directly committed to that directory) and then I think it's ready.

Again, once I can compile tests, bazel test //... and bazel test @cargo_raze_examples//... should be the only commands needed here (but buildifier should also be added).

[UebelAndre]

@acmcarther Is it possible to have build artifacts published on this github project? I'm interested in being able to download a pre-built binary for use in a repository rule.

[UebelAndre]

Ok, I've solved the issue I mentioned in https://github.com/google/cargo-raze/issues/313#issuecomment-749212104 and the entire repo is buildable in Bazel. Once some other PRs go through, I'll open a PR for https://github.com/UebelAndre/cargo-raze/tree/bazel

[UebelAndre]

@acmcarther is this still time sensitive?

[acmcarther]

I think the deadline was pushed back but I'm not sure how long.

[UebelAndre]

Been testing the Bazel changes while my other PRs are being reviewed. Hopefully Bazel support and migrating to BuildKite/BazelCI will still do the trick.

[UebelAndre]

It seems like TravisCI is no more? Got this when working on https://github.com/google/cargo-raze/pull/351

[acmcarther]

Setting up BuildKite now. It will live at https://buildkite.com/bazel/cargo-raze

[UebelAndre]

Just FYI

[acmcarther]

Yeah I'll get that sorted out. It seems I've already not followed the steps I should have (I created the pipeline manually using my super duper powers instead of onboarding through bazelbuild/continuous-integration.

[acmcarther]

Filed https://github.com/bazelbuild/continuous-integration/issues/1084

[UebelAndre]

@acmcarther Are PRs hooked up to try and use Buildkite?

I tried rebasing a PR and didn't see buildkite (after the response in https://github.com/bazelbuild/continuous-integration/issues/1084)

[acmcarther]

Sorry for the terrible turnaround time. I realize I'm holding up literally everything by not fixing this. Had/have some IRL stuff eating my time up.

I'm setting aside the rest of the work day today to get this in good shape (particularly to unblock https://github.com/google/cargo-raze/issues/355)

[acmcarther]

Status: Still working on this.

Update:

• //impl:cargo_raze_lib_test is non hermetic because it depends on the cargo binary
  • One option, pass the cargo binary from the toolchain into the rust_test rule
  • Obstacles:
    • Not clear (to me) how to (a) select the toolchain (e.g. @rules_rust//:toolchain) and (b) extract the cargo bin from it in the context of a rule invocation
    • rust_test doesn't appear to have a way to set an environment variable ($CARGO is the setting used in cargo-raze for this)
  • Other option: Install rust toolchain
  • Working on this now. A bit finnicky

WIP branch is https://github.com/google/cargo-raze/pull/356

[UebelAndre]

* rust_test doesn't appear to have a way to set an environment variable ($CARGO is the setting used in cargo-raze for this)

I thought env was a common attribute for tests (at least in Bazel 4.0) https://docs.bazel.build/versions/master/be/common-definitions.html#common-attributes-tests

[acmcarther]

This attribute only applies to native rules, like cc_test, py_test, and sh_test. It does not apply to Starlark-defined test rules.

[acmcarther]

(i didn't scrutinize this heavily -- i just tried it with whatever my local bazel version was, found it didn't work, and moved on)

[UebelAndre]

* Not clear (to me) how to (a) select the toolchain (e.g. `@rules_rust//:toolchain`) and (b) extract the cargo bin from it in the context of a rule invocation

I think you'd have to select on the specific toolchain names. eg:

rust_darwin_aarch64
rust_darwin_x86_64
rust_freebsd_x86_64
rust_linux_aarch64
rust_linux_x86_64
rust_windows_x86_64

[UebelAndre]

This attribute only applies to native rules, like cc_test, py_test, and sh_test. It does not apply to Starlark-defined test rules.

Ah, sadness. Feature request time! 😄

[acmcarther]

As mentioned in the linked CL, i'm out of time to work on this today, so it's doomed to be bork for an additional day. I'll look again tomorrow morning.

[acmcarther]

In the time I was sorting RL stuff out, it seems that @UebelAndre fixed the outstanding issues.

CI is currently failing because the windows build is broken. I think this can be mitigated independently. I'll submit a PR that disables the windows integration, then ask continuous-integration maintainers to make the build pipeline public.