For example, ArchiveFilesV2:
C:\Work\GitHub\IanKemp\azure-pipelines-tasks> node make.js build
<thousands of lines of output skipped>
------------------------------------------------------------
Building: ArchiveFilesV2
------------------------------------------------------------
> getting task externals
Downloading file: https://vstsagenttools.blob.core.windows.net/tools/7zip/1/7zip.zip
C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\sync-request\index.js:27
throw new Error(res.stderr.toString());
^
Error
at doRequest (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\sync-request\index.js:27:11)
at downloadFile (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:384:22)
at downloadArchive (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:424:27)
at C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:617:33
at Array.forEach (<anonymous>)
at getExternals (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:612:25)
at C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make.js:189:13
at Array.forEach (<anonymous>)
at Function.target.build (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make.js:154:14)
at Object.global.target.<computed> [as build] (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\shelljs\make.js:28:26)
Similar issue with AzureAppServiceManageV0, I didn't check any others.
Important to note that manually downloading the specified ZIP files succeeds.
I am not behind a proxy.
Seems like there is a bug or issue in the sync-request module, after editing its index.js file to spit out useful diagnostic info:
var res = spawnSync(process.execPath, [require.resolve('./lib/worker.js')], {input: req});
if (res.status !== 0) {
throw new Error("Expected status 0, got " + res.status + ": " + res.stderr.toString());
}
I get:
> getting task externals
Downloading file: https://vstsagenttools.blob.core.windows.net/tools/7zip/1/7zip.zip
C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\sync-request\index.js:27
throw new Error("Expected status 0, got " + res.status + ": " + res.stderr.toString());
^
Error: Expected status 0, got null:
at doRequest (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\sync-request\index.js:27:11)
at downloadFile (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:384:22)
at downloadArchive (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:424:27)
at C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:617:33
at Array.forEach (<anonymous>)
at getExternals (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make-util.js:612:25)
at C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make.js:189:13
at Array.forEach (<anonymous>)
at Function.target.build (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\make.js:154:14)
at Object.global.target.<computed> [as build] (C:\Work\GitHub\IanKemp\azure-pipelines-tasks\node_modules\shelljs\make.js:28:26)
So res.status is null but the module is expecting it to be zero.
For some reason, package.json in this project uses version 3.0.1 of sync-request, which was released more than 3 years ago.... the latest version of this module is 6.1.0.
The issue I'm encountering is documented in the sync-request repo: https://github.com/ForbesLindesay/sync-request/issues/81 and was fixed by them.
I attempted to upgrade the version of sync-request to 5.0.0 but this threw hundreds of TypeScript errors because, for equally inexplicable reasons, this project locks its version of TypeScript to the equally-ancient 2.3.4.
I then attempted to upgrade TypeScript to get around this, but that caused all sorts of errors further down the build pipeline. So I then used the nuclear option and updated every Node package to its latest version, but that also caused things to break.
Honestly this is an embarrassment of note. If you're going to use Node and its ecosystem, do it properly and keep things updated! The situation of the build process in this repo is shocking and reflects extremely poorly on Azure itself, and honestly makes me wonder exactly how reliable Azure is.
Fix it.
I too am running into this and would like to use recent versions of everything. Is there an ETA for this?
Same here. Looks like this code is no longer compatible with current node stable versions. Using an old v11.15.0 node things work. Using a current 12.11.0 it fails with this error.
I am hitting the same problem here:
https://dev.azure.com/CppBuild/CppBuildTasks/_build/results?buildId=3780&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9
This also prevented me from contributing. Is there any easy workaround for this issue?
Running into this as well. So if I understand correctly, the only way to build azure-pipeline-tasks locally is to downgrade node? Is there a simple way to do this?
Hello @stephenmichaelf, is there an update on the ETA of this issue? Thanks!
Same here, please fix it. Not able to build HelmInstallerV1 for on-premises Devops 2019.
It should be fixed yes; but the issue is somewhere in the combination of nodejs and sync-request. I encountered the same issue when trying to build the AzurePowerShellV5 task.
For me it started to work after I installed nodejs v8.17.0 and npm v6.9.0.
For anyone following this still. It seems that a PR is in the works to bump this version up for sync-request. https://github.com/microsoft/azure-pipelines-task-lib/pull/665
Most helpful comment
For some reason,
package.jsonin this project uses version 3.0.1 ofsync-request, which was released more than 3 years ago.... the latest version of this module is 6.1.0.The issue I'm encountering is documented in the
sync-requestrepo: https://github.com/ForbesLindesay/sync-request/issues/81 and was fixed by them.I attempted to upgrade the version of
sync-requestto 5.0.0 but this threw hundreds of TypeScript errors because, for equally inexplicable reasons, this project locks its version of TypeScript to the equally-ancient 2.3.4.I then attempted to upgrade TypeScript to get around this, but that caused all sorts of errors further down the build pipeline. So I then used the nuclear option and updated every Node package to its latest version, but that also caused things to break.
Honestly this is an embarrassment of note. If you're going to use Node and its ecosystem, do it properly and keep things updated! The situation of the build process in this repo is shocking and reflects extremely poorly on Azure itself, and honestly makes me wonder exactly how reliable Azure is.
Fix it.