Set up CI with Azure Pipelines #16
Conversation
![azure-pipelines[bot]](https://avatars.githubusercontent.com/in/9426?s=60&v=4){kind=small}
mykmelez
force-pushed
the
azure-pipelines
branch
from
8457969
to
7dc94e4
Compare
Just FYI: I hate that Travis and TC configuration starts with a dot, 'cuz it hides critical configuration (that matters more to me than most people, honestly) and 'cuz it makes |
There was a problem hiding this comment.
This is pretty cool, but how do you get anything out of these jobs? I don't see a declaration of a .so/.dylib/.dll or anything -- I guess you really just care that this is building and that tests are passing?
Looking ahead to mobile SDKs to rkv, I am assuming that we'll focus the application-services TC apparatus on them and use https://github.com/ncalexan/rust-android-gradle for building and publishing. Is that acceptable?
.azure-pipelines.yml
Outdated
| - template: .azure-pipelines-template.yml | ||
| parameters: | ||
| name: macOS | ||
| vmImage: macOS-10.13 |
There was a problem hiding this comment.
Seriously? This is pretty hot. I didn't know you could run macOS in Azure.
That's reason enough for me to move it back to the default, non-prefixed filename, which I've done in
At this stage I just care that it builds and passes tests (i.e. can be an AppVeyor replacement), so I'm only using a build pipeline. But Azure Pipelines provides what it calls a "release pipeline", which (self-referentially) "defines the end-to-end release pipeline for an application to be deployed across various stages." See Release pipelines and release names for more info.
Yes, that's great. I didn't envision Azure usage as replacing TC, only AppVeyor. In the future, I'd like to see rkv use the same machinery as our other Rust components, for both CI and deployment.
Indeed, so hot. |
(In the future, we should consider moving these kinds of files into a dedicated subdirectory, like build or config.) |
Inspired by mozilla/lmdb-rs#16. I'm not sure if this will work. But it looks right.
Inspired by mozilla/lmdb-rs#16. I'm not sure if this will work. But it looks right.
Inspired by mozilla/lmdb-rs#16. I'm not sure if this will work. But it looks right.
Inspired by mozilla/lmdb-rs#16. Surprisingly, I was able to get this working on the first attempt. This is the easiest cross-platform CI I have ever set up for a project. I'm in awe.
@ncalexan Appveyor has been slow to build this project on Windows (and Linux, for that matter), and Azure Pipelines seems to be much quicker, so we should use it to tighten the feedback loop.
The YAML configuration files on this branch are adapted from the ones that @LegNeato landed for graphql-rust/juniper#259, which may have themselves been adapted from the ones in parcel-bundler/parcel#2047.
The primary difference is that I moved azure-pipelines.yml to .azure-pipelines.yml (leading period) to hide it from default directory listings like we do with the other CI service configuration files (.travis.yml, .appveyor.yml). Azure assumes the in-repo configuration file for a web-configured "project" is called azure-pipelines.yml without a leading period, but the project can be configured to use any filename.
I spent a bunch of time trying to figure out how to define the
cargo testscript only if rustup_toolchain isnightly, since lmdb-rs tests use#![cfg_attr(test, feature(test))], which requires a nightly build of Rust.But I couldn't figure out how to test for that value in an Azure conditional, so I replaced it with a bash/cmd.exe conditional within the script, which is what we do on Travis. There might be a more elegant solution, however.
There appears to be a "mozilla" organization in Azure, but I haven't yet figured out who owns it, so I'm currently piping this line in my "mykzilla" organization. Probably the CI should move to a more general Azure org, although I think that's orthogonal to the configuration files themselves, which is what we're landing here.