Build status bade shows Never built

[abatishchev]

Here's what it shows right now:

Is its url correct?

[commonsensesoftware]

It's correct, but the badge is a misnomer. What's really happening is that the build hasn't run for a while. I'll have to check, I can't remember if the badge uses the CI or Release build. I think it was the release build. Effectively, if the build hasn't run in a while, then the history drops off and it will report never built. In reality, it means it hasn't built in a while. The release build definitely hasn't built in several months; it is intentionally run manually. I've also been working on fixes, but haven't started a PR - yet. There aren't many PRs from the community, which means there just isn't a ton of build activity.

Hopefully that clears things up. I'll look kicking off a build just so the badge gets updated. 😛 Thanks for point it out.

[abatishchev]

@commonsensesoftware I'm sorry! I somehow missed your response. And thanks for the detailed explanation! I completely forgot about the retention policy thing.

Here's few ideas:

• Increase the retention policy (to the maximum, should be ok since the project isn't often built, if built at all)
• Run a build in schedule near the end of the retention (let's say 29 and 30 days respectively)
• Remove the badge altogether since it's not very needed (since the project isn't often built)

I tried to run the build myself but got an error

Request failed. GitHub responded with result: 'Moved Permanently'

Looks like more work would be needed to resurrect the CI/CD pipeline. Would you, please? Or rather prefer a volunteer? I can probably can take a look too

[commonsensesoftware]

The release build, in particular, has historically been built inside MS for code signing. I don't have a date - yet, but this will be changing in the not too distant future. The builds existed before the days of YAML and Azure Pipelines support, which is why there is no azure-pipelines.yml file.

The CI build, however, is literally two steps:

1. Install .NET SDK
2. Run dotnet test (which restores, builds, tests, and publishes the results)

The release build is effectively the same with yield points for signing and NuGet packaging. That shouldn't be interesting for others. It's very unlikely I'll ever automate publishing the release build, which is more or less CD for this project. Release builds do not occur that often, so it's manageable. Making a package publishing mistake requires rebuilding and republishing (and has happened in rare occasions). I manually spot-check everything one last time before publishing, which a simple 1-line PowerShell command (e.g. dir *.nupkg | %{dotnet nuget publish $_}).

The error you have shown looks to be related to cloning or something else Git-related as opposed to build. I am aware that there is an issue on some *nix-based OSes with case-sensitive file systems. The casing of the Directory.Build.* files matters to MSBuild on those systems. This will be addressed in an upcoming change. Beyond that, I'm not aware of any build issues.

[abatishchev]

When I go to https://microsoft.visualstudio.com/OS/_build?definitionId=25025 and click Run pipeline, I'm seeing this error:

When I exported the pipeline to JSON, I can see that it points to the old repo's location:

"apiUrl": "https://api.github.com/repos/microsoft/aspnet-api-versioning",
"branchesUrl": "https://api.github.com/repos/microsoft/aspnet-api-versioning/branches",
"cloneUrl": "https://github.com/microsoft/aspnet-api-versioning.git",
"manageUrl": "https://github.com/microsoft/aspnet-api-versioning",
"refsUrl": "https://api.github.com/repos/microsoft/aspnet-api-versioning/git/refs"

Also the agent settings point to non-existent queue and the pool is null:

"queue": {
    "_links": { "self": { "href": "https://microsoft.visualstudio.com/_apis/build/Queues/21652" } },
    "id": 21652,
    "url": "https://microsoft.visualstudio.com/_apis/build/Queues/21652",
    "pool": null
  }

So looks like the migration of the repo and then some housekeeping in the ADO account broke it badly.

[commonsensesoftware]

You didn't mention that you had internal access to the build. I'll have some reach out to you. ;)

[abatishchev]

Sorry! Didn't intend to be deceptive. Yes, I'm an FTE at Microsoft. Happy to chat, see if I can help.

[commonsensesoftware]

The backend is currently in flux as things transition to the .NET Foundation. The internal MSFT build servers will cease to be used. The new landing page is in the main branch. It currently doesn't have a status because the build hasn't bee setup yet.

To pair with this issue, I will remove the badge from the README because it's impossible for it to ever build again the way it used to. Thanks.