Cargo: Question: specifying latest build on branch for Azure Pipelines

[matthewkmayer]

First a big thank you to everyone keeping cargo going. 😄

Problem

I'd like to have the latest build of a branch from Azure Pipelines shown as the build badge for a crate. Currently, TravisCI and AppVeyor are shown fine with the latest build of the master branch.

https://doc.rust-lang.org/cargo/reference/manifest.html says the buildid field is required for azure-devops which I assume is another name for Azure (DevOps) Pipelines. This field changes on every new build, so buildid 1 can refer to one commit on master and buildid 3 can refer to the next commit on master.

Ideally I'd like to omit the buildid and have the build badge show the latest build of the specified branch, like TravisCI badges do. The cargo docs linked above state if it's omitted, buildid 1 will be used, which does not appear to be the latest build of the specified branch.

How can I get a build badge on the latest build of the specified branch? Is this something Azure Pipelines needs to change or can cargo do it? Is this issue better suited to be in the crates.io repo?

Thanks! 😄

[calebcartwright]

FWIW - despite the name, I believe buildid is actually used for the pipeline/definition id. The badge on crates.io will display the latest status for the definition/pipeline specified by that id. I do not believe it's possible to specify a specific _branch_ though for the azure pipelines badge though unfortunately

[matthewkmayer]

👍 that would make more sense. 😄

https://dev.azure.com/matthewkmayer/Rusoto/_build?definitionId=1 refers to the entire build pipeline. The definitionId=1 part is probably what the cargo docs refer to. It's confusing because https://dev.azure.com/matthewkmayer/Rusoto/_build/results?buildId=127 is a particular build, and has buildId=127 in it. It's easy to read buildId in the cargo docs and assume it maps to the same query parameter in Pipelines.

If this is correct, any guidance for updating documentation to make this more clear?

[calebcartwright]

It's easy to read buildId in the cargo docs and assume it maps to the same query parameter in Pipelines.

Agreed. buildId has a specific meaning in Azure DevOps world that can certainly create confusion. There is a note in the docs that calls out the build value as definition id, albeit on the far right:

# Azure DevOps: `project` is required. `pipeline` is required. `build` is optional; default is `1`
# Note: project = `organization/project`, pipeline = `name_of_pipeline`, build = `definitionId`

[matthewkmayer]

Thanks! Sounds like it should all work fine then.

What would it take to rename the build field to definitionId to make this more clear?

[calebcartwright]

What would it take to rename the build field to definitionId to make this more clear?

Just my two cents again.. but I feel like there's some additional challenges to changing that now, since there's already folks (like myself) that have their badges set up using the existing build field. Perhaps there's a way to make that change and maintain backwards compatibility that the Cargo team would consider though.

I imagine such a change would require changes to crates.io as well so you may want to consider asking over at https://github.com/rust-lang/crates.io too.

[matthewkmayer]

Since this should all work as expected after a careful reading, I don't think there's anything left in this issue.

Thanks for the help @calebcartwright ! 😄