Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ed Page
    @epage
    Were you using caches or pipeline artifacts?
    Jon Gjengset
    @jonhoo
    Pipeline artifacts
    Jon Gjengset
    @jonhoo
    This move makes me seriously want to switch to GitHub Actions: https://blog.rust-lang.org/inside-rust/2019/11/14/evaluating-github-actions.html
    Ed Page
    @epage
    Interesting
    Nick Babcock
    @nickbabcock
    Oh wow, and there seems like there is already some basic infrastructure for rust actions: https://github.com/actions-rs/cargo
    (that is, why beta fmt and tarpaulin are failing?)
    Ed Page
    @epage
    If I'm looking at the right failures
    Dirkjan Ochtman
    @djc
    huh, right, this actually has the proper output
    earlier I didn't see these for some reason
    Dirkjan Ochtman
    @djc
    error: --no-default-features is not allowed in the root of a virtual workspace
    @jonhoo are you going to fix this stuff? or are you moving over to GH actions? :)
    Jon Gjengset
    @jonhoo
    So, one challenge here is that there isn't a backwards-compatible way to set these flags
    But maybe the trick here is to detect whether the crate is a workspace and set the flags accordingly
    That'd be the easy fix
    Sadly it means that for workspace crates we do not test the crates of the workspace with various feature combinations
    My inclination, as discussed earlier, is still to just provide a really robust Rust installation script, and maybe a "good default script", and for everything else have people write their own cargo invocations manually
    I'll do a quick-fix and then submit a PR that removes nearly all the templates
    Jon Gjengset
    @jonhoo
    Also, it's pretty stupid because --no-default-features should work just fine in a workspace
    Just like --all-features (rust-lang/cargo#7525)
    Dirkjan Ochtman
    @djc
    Yeah, I really dislike how cargo has just sort of cavalierly broke all these setups
    Jon Gjengset
    @jonhoo
    @djc you may also want to watch rust-lang/cargo#5364
    Jon Gjengset
    @jonhoo
    btw, this is what I'm imagining the repo becoming in the next version: crate-ci/azure-pipelines#73
    that is, just install and a very opinionated and inflexible default
    and then instructions to basically write your own azure-pipelines (using the template just for installation) if you need something fancier
    Dirkjan Ochtman
    @djc
    I think I will probably end up moving over to GH actions after all
    Azure Pipelines integration with GitHub is pretty bad
    Jon Gjengset
    @jonhoo
    I'm not convinced it's that much better as a platform, except maybe for integration purposes. In terms of specification languages they are basically identical. And since MS owns both, I'm pretty sure they'll converge (and probably even run on the same infra)
    Dirkjan Ochtman
    @djc
    Not sure I agree
    Technically it makes sense that they're more or less equivalent
    However Azure seems to have a large amount of UX paper cuts that collectively make me wary of dealing with it
    Jon Gjengset
    @jonhoo
    Yeah, that's certainly true
    Jon Gjengset
    @jonhoo
    As for crate-ci/azure-pipelines#73, I'm inclined to merge it after fixing up the docs. Will also make the project much more maintainable. @epage how do you feel about that direction.
    (would be released as v0.3)
    Jon Gjengset
    @jonhoo
    @epage I assume this is what you fixed in the merged PR?
    I pushed it to v0.3 as well
    Ed Page
    @epage
    Thanks
    I hope my pr fixes it; im just confused at why we get different behavior
    Dirkjan Ochtman
    @djc
    I've moved all my Rust CI to GitHub Actions for now... thanks for the support!
    Jon Gjengset
    @jonhoo
    :+1: Let us know how you find it after a bit of time?
    Jon Gjengset
    @jonhoo
    Thoughts on changing default.yml to also run cargo deny check (https://github.com/EmbarkStudios/cargo-deny) if a deny.toml file exists?
    Jon Gjengset
    @jonhoo
    Actually, I take that back. Compiling cargo deny takes too long (same as our issue with cargo audit)
    Ed Page
    @epage
    They offer pre-built binaries. We could use my gh-install template to download them
    Jon Gjengset
    @jonhoo
    Interestingly enough, Pipelines caching works pretty great for this: https://github.com/jonhoo/flurry/blob/d3dae0465b37b7f12c4f0d58a16f36fb1d8c1596/azure-pipelines.yml#L11-L31
    Andrey Cherkashin
    @andoriyu
    I forgot where we were with cargo-suity. Is it still usable or is there something that is better out there?
    Ed Page
    @epage

    @jonhoo unsure if you are still monitoring this and using Azure Pipelines but was hopeful that you've run into this problem. I've been having problems with matrix jobs and continueOnError

    My PR updates a dependency that breaks on nightly (and I have some bad lints on stable clippy)
    crate-ci/committed#161
    (I also am fixing a bad copy/paste for my continueOnError)

    and yet my pipeline fails
    https://dev.azure.com/crate-ci/crate-ci/_build/results?buildId=1348&view=logs&jobId=d4cfe60d-5097-5e26-e7da-808cd0fd48ff&j=e2feff2c-69b0-5038-e0b3-b4ab760f2c20&t=a306d88a-940f-545e-a9f3-6a4ab0cf4d1f

    I've run into this before and ended up giving up and not using matrix jobs but that'd be a pain in this nightly case.

    Jon Gjengset
    @jonhoo
    Yeah, I think I've run into this too, and I believe it's an issue with pipelines specifically. It's been a while, but I think what I ended up doing was something like this: https://stackoverflow.com/questions/58811721/continue-on-error-but-still-report-as-error-in-azure-pipelines