Batch parameter leads to azure pipelines check failure#237
Batch parameter leads to azure pipelines check failure#237jamesmyatt wants to merge 1 commit intopython-jsonschema:mainfrom jamesmyatt:check-azure-pipelines
Conversation
Fails locally for me
|
I'm pretty sure this is an upstream issue (e.g. microsoft/azure-pipelines-vscode#224), but I think it's still useful to confirm whether it's an issue here, and whether there's any regression. |
|
This is not so much a PR as it is a bug report, right? Would you be willing to reopen it as an issue? GitHub provides no facility for converting PRs to issues. I'm quite tempted to uncritically slap this with the As for the weirdness of the message you get in this case... I can tell you how we got that message, but I can't really fathom why the schema is structured in a way that leaves validators in this situation. You can see the full slew of errors on all branches of the schema by running with the verbose flag: It's almost unreadable in this case, since it's a branch-by-branch evaluation finding no joy and reporting all of the errors. I'm aware of the level of stink about this whole thing, especially for an end user who "just" wants working validation. But without a more serious attitude from Microsoft about making the schema usable and interoperable, I'm not sure I can do much. e.g. I could offer a flag to stringify bools, but who knows what else that might break? |
|
So, yes. It's an upstream issue, in the sense that the azure schema is wrong. I think the relevant issue here is I had to raise the PR to get it to run the tests in CI to isolate any issue that may have been local to my machine. For check-jsonschema, I wonder whether any of the following options are a good idea:
|
|
I'm going to be closing this because PRs are not the correct way to report and track issues. I think the best thing to do is to report these issues, as you encounter them, on the pipelines-vscode repo, https://github.com/microsoft/azure-pipelines-vscode/ Feel free to refer them back to me, FWIW. We can do the same silly dance we did last year, in which I try to tell them what needs to be fixed, and they tell me that I should blackhole my feedback into their forums. I am -- I'm sure it's quite clear -- pretty pessimistic about any good outcome. But at least you'll be able to nag people in a better position to fix this.
This is something I've thought of before, but I've had to reject the idea. The schema is enormous, broken in innumerable ways, and the full Azure Pipelines definition language is not even expressible in JSON Schema (which is why there's already a transformer for it to handle some of the feasible cases).
Based on what I've seen, it won't be fixed, or it will be fixed and broken again. (I also have more philosophical objections to tests being used in this way, but it's not super relevant.)
This seems to me like the only path forward in which I can do anything here. The sloppy handling of booleans is probably going to persist. I can at least doc that bool fields are often broken in Azure, on the FAQ page. |
|
Agreed. Thanks |
This file fails locally for me, but is definitely supported. See https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/trigger?view=azure-pipelines#trigger-batch-branches-paths-tags.
Using 0.21.0 installed via pipx on Windows.