Open archerzz opened 4 months ago
A minimal readme.md to repro the EINVAL is:
use-extension:
"@microsoft.azure/classic-openapi-validator": "~1.1.5"
input-file: sample.yaml
ResourceHealth's config is getting this through:
azure-validator: true
This imports classic-openapi-validator if we don't also set v3: true
A workaround is to add v3: true
to the affected autorest config.
We are running into this error as well. We are using the legacy C# generator, so the v3: true
flag does not work in our case. Any suggestions for a different workaround?
Here is another repro:
input-file: https://github.com/Azure/azure-rest-api-specs/blob/d374d03801e97737ddb32e01f20513e7b2bbd9c3/arm-storage/2015-06-15/swagger/storage.json
csharp: true
legacy: true
Well, if legacy one is still needed, and if your problem persists in your build pipelines, the only workaround could be changing your build agent to a linux one (i.e. ubuntu-latest) from windows (windows-latest).
That worked for my case.
Before filling a bug
Describe the bug
Starting from May 17, there were autorest errors in one of our pipeline: https://dev.azure.com/azure-sdk/internal/_build?definitionId=5990&_a=summary
After analysis, we thought it's due to a security enhancement introduced in node v18.20.2: https://github.com/nodejs/node/issues/52554 The fix is to pass
{ shell: true }
when invokingspawn()
. I searched the codes ofautorest
, and I found there are several invocation ofspawn()
. I guess they are for invoking generators. Can we have an alpha build so that we can try on our pipeline to verify the fix?Expected behavior
autorest
should run without error on Windows server 2022 + node v18.20.2Additional context