Collaborate with crate-ci?

[epage]

crate-ci is trying to be a central place for documentation and supporting tools to help people have the latest greatest CI. It was born out of frustration with everyone blogging about their own approach and trying to figure out how to synthesize it all.

We have some basic templates and have started on an equivelant of trust's tool to download binaries from github releases

See https://github.com/crate-ci/resources

[xoac]

Collaborate with crate-ci?

Yes

I would suggest to use resources for azure:
ci/task/...
ci/jobs/...

where task could be install cargo, install nightly etc. and jobs rustfmt, clippy. I have planned to change to this structure in v0.2.0 but I didn't have enough time.

It should be easy to create complicated jobs just with tasks.

It's nice sb started do work with my repo <3

I would suggest also use cargo-generator to easy creates working CI

[epage]

Yes, we've started a discussion about the idea of having tasks which includes the author of the existing Rust task. He was planning on taking our ideas and running with it but haven't heard back in a while so I'm sure life has caught up with him like it has the rest of us :)

btw we've now joined efforts with rusty-pipes and so most of the discussion / development has moved to https://github.com/crate-ci/azure-pipelines . I need to update resources repo to call this out.

[epage]

Also, for real-time conversations, there is always gitter

[xoac]

I just merged a new idea of how I see CI with azure-pipelines to master. Let me guys know what you think about it.

The idea is to make it simple: for example if you know how to use cargo check you should know how to use ci/jobs/cargo-check.yml since all parameters have the same names

[epage]

I considered such an approach but it made me wonder what value it provides over just calling cargo check directly. What kind of benefits have you seen from this approach?

[xoac]

Oh. You are right it don't look good. I was more thinking about making it fully customizable and at the same time easy to use.

One advantage I see to easy pass parameters. If you specify in some ci/scenario

parameters: 
  features:
    - one
    - two

you can then pass them east to all ci/jobs:

jobs:
- template: jobs/cargo-check.yml
  parameters: ${{ parameters }}
- template: job/cargo-build.yml
  parameters: ${{ parameters }}

but it's not worth the complication.

But I still think you are right. Cargo job template cloud look like this:

template: cargo.yaml@1
parameters:
  rust: stable
  cli-parameters: "check --release --benches --features one,two"

instead of this:

template: cargo-check.yaml@2
parameters:
  rust: stable
  release: true
  benches: true
  features:
    - one
    - two

@1 will be much more simple and useful.

Let me know what you guys think about creating sub-folders like steps, jobs and scenarios (of course we can rename them to more meaningful) I see some advantages over just ci folder.

---

Here are some thinks that make me confusing in crate-ci/azure-pipelines:

For example https://github.com/crate-ci/azure-pipelines/blob/master/azure/cargo-check.yml
There is a parameter all_futures but in cargo you use flag all-futures this is making people confuse. (there is more parameters that just differ _ and -).
Another confuse thing -- there is no way for people that included crate-ci/azure-piplines template to just easy check one future or a bench of futures together.

And also cross:
first of all it's not cross - it's native build just on different agents and the second argument against it's why just don't call it strategy-matrix allow users use standard azure pipelines tool to specify they wanna test on Linux, Linux and MacOS or any other platform azure is support. And make it default to Linux (and why default is just one platform instead of all systems).

I thinking about template repo should be like everybody could use them without a lot of learning this tool (ideally just look for examples).

If you guys agree we can team up on crate-ci/azure-pipelines

[epage]

Let me know what you guys think about creating sub-folders like steps, jobs and scenarios (of course we can rename them to more meaningful) I see some advantages over just ci folder.

I think this could be a reasonable re-org though I'm unsure the best way to handle this without breaking existing uses. I'd recommend creating an issue over there.

Here are some thinks that make me confusing in crate-ci/azure-pipelines:

So I can't answer all of that, I'd recommend talking to Jon over on gitter.

One thing I can say is that the high level jobs are meant to cover the 90% case in a good enough way. For example, I have a project that is only using the rustup step because my build times would be too long under the default configuration and I knew enough about my project to be able to optimize it. Most of my projects use the defaults though.

[xoac]

@epage In my repo for most people are scenarios or stages (you called it high level jobs) and copy-past examples. For others are easy to configure jobs and steps -- that should be enough to make your project work. I know this repo is still a mess. But I did it to show how I think it should looks - maybe I am just wrong like with appends arguments :)

[xoac]

I archived the repo and linked to crates-ci