Open mvldk opened 2 days ago
There is also a related issue in azure-functions-core-tools repo. Indeed this could be due to a change in the versioning pattern that includes an additional prepended 'v'.
Unless the file structure for azure function core tools is reverted, I think that the problem needs to be fixed in the pipeline task. The pipeline task contains logic to build the download URL, which would no longer work:
function getDownloadUrl(version: string) {
let downloadUrlFormat = 'https://github.com/Azure/azure-functions-core-tools/releases/download/%s/Azure.Functions.Cli.%s.%s.zip';
switch (os.type()) {
case 'Linux':
return util.format(downloadUrlFormat, version, 'linux-x64', version);
case 'Darwin':
return util.format(downloadUrlFormat, version, 'osx-x64', version);
case 'Windows_NT':
default:
return util.format(downloadUrlFormat, version, 'win-x86', version);
}
}
The same version string, neither "v4.0.6543" nor "4.0.6543", will work in both places of the download URL, 'https://github.com/Azure/azure-functions-core-tools/releases/download/%s/Azure.Functions.Cli.%s.%s.zip'. The "v" prefix is necessary in the first location but shouldn't be there in the second location.
For now, I made it work for my pipeline by forcing it to use the older version but this need to be resolved:
- task: FuncToolsInstaller@0
displayName: 'Install Azure Functions Core Tools'
inputs:
version: '4.0.6280'
Maybe change the pipeline task to use the link provided in the feed as browser_download_url
? That one is set to the correct value.
https://api.github.com/repos/Azure/azure-functions-core-tools/releases/latest
@mnemcik-visma It's a bit more tricky than that. There are several assets in the release bundle, each with a specified browser_download_url
. Code would have to parse asset properties to find the one relevant for the OS type.
Same issue affecting a build pipeline on my end.
@mnemcik-visma It's a bit more tricky than that. There are several assets in the release bundle, each with a specified
browser_download_url
. Code would have to parse asset properties to find the one relevant for the OS type.
That is exactly what I'd do by design rather than create a strong dependency on file naming conventions defined in a 3rd party repository.
Hi @mvldk @Ehsanshiri @rrr-michael-aquilina @mnemcik-visma Could you please check if still you are facing the issues? I created a new release with FunctoolsInstaller task but I am unable to reproduce the issue with the repro steps shared above.
Hi @v-schhabra Now it's working fine for the latest version. There has been an update for it here: https://github.com/Azure/azure-functions-core-tools/issues/4156#issuecomment-2469230570
Works correctly for me with version 4.0.6594
EDIT: Kind of works correctly, as there seems to be a problem with this version of Azure Functions Tools, we're getting error when calling func start
:
Failed to start the inproc6 model host. An error occurred trying to start process '/opt/hostedtoolcache/func/4.0.6594/x64/in-proc6/func' with working directory '/home/vsts/work/1/s/Service/src/Api/bin/output'. Permission denied
Reverted back to 4.0.6280, all works fine with this version.
Since they changed the release file structure back in Azure/azure-functions-core-tools
, the FuncToolsInstaller
task also works for me using latest
version - but version 4.0.6543
still fails.
I would still suggest to follow through on the suggestion from @mnemcik-visma to rely on the release meta data instead of fragile naming convention:
Maybe change the pipeline task to use the link provided in the feed as
browser_download_url
? That one is set to the correct value. https://api.github.com/repos/Azure/azure-functions-core-tools/releases/latest
I do get the same error as @mnemcik-visma with version 4.0.6594
. But I am not sure if that is related to this issue:
Kind of works correctly, as there seems to be a problem with this version of Azure Functions Tools, we're getting error when calling
func start
:Failed to start the inproc6 model host. An error occurred trying to start process '/opt/hostedtoolcache/func/4.0.6594/x64/in-proc6/func' with working directory '/home/vsts/work/1/s/Service/src/Api/bin/output'. Permission denied
New issue checklist
Task name
FuncToolsInstaller
Breaking task version
0
Last working task version
0
Regression Description
Azure function core tools seems to have changed their release download file structure - notice the added "v" before the version number in the folder:
https://github.com/Azure/azure-functions-core-tools/releases/download/v4.0.6594/Azure.Functions.Cli.linux-x64.4.0.6594.zip https://github.com/Azure/azure-functions-core-tools/releases/download/v4.0.6543/Azure.Functions.Cli.linux-x64.4.0.6543.zip https://github.com/Azure/azure-functions-core-tools/releases/download/4.0.6280/Azure.Functions.Cli.linux-x64.4.0.6280.zip https://github.com/Azure/azure-functions-core-tools/releases/download/4.0.5907/Azure.Functions.Cli.linux-x64.4.0.5907.zip https://github.com/Azure/azure-functions-core-tools/releases/download/4.0.5858/Azure.Functions.Cli.linux-x64.4.0.5858.zip
As a result, FuncToolsInstaller fails to download the tools when configured with version "latest": Error: Unexpected HTTP response: 404 (see logs)
Environment type (Please select at least one enviroment where you face this issue)
Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Azure DevOps Server Version (if applicable)
No response
Operation system
ubuntu-22.04
Relevant log output
Full task logs with system.debug enabled
Repro steps