I am using helm installer task in ado yaml pipeline. It has been working fine for more than a year now. All of a sudden today I am seeing below error.
##[error]Error: Unable to locate executable file: 'helm'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
My yaml file:
- task: HelmInstaller#0
inputs:
helmVersion: ${{ parameters.helmVersion }}
installKubectl: true
checkLatestHelmVersion: false
Did anyone face this issue ?
Further logs from the task:
Downloading: https://api.github.com/repos/helm/helm/releases
(node:144) Warning: Use Cipheriv for counter mode of aes-256-ctr
Downloading: https://get.helm.sh/helm-v3.10.2-linux-amd64.zip
Extracting archive
/usr/bin/unzip /__w/_temp/helm-v3.10.2-f8239f1e-9c15-41c1-b7db-776e2cbaa057.zip
Archive: /__w/_temp/helm-v3.10.2-f8239f1e-9c15-41c1-b7db-776e2cbaa057.zip
creating: linux-amd64/
inflating: linux-amd64/helm
inflating: linux-amd64/LICENSE
inflating: linux-amd64/README.md
Caching tool: helm 3.10.2 x64
Prepending PATH environment variable with directory: /__t/helm/3.10.2/x64/linux-amd64
Verifying helm installation...
##[error]Error: Unable to locate executable file: 'helm'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
Finishing: HelmInstaller
I've had the same problem. We are running our pipeline on our own agent, so was able to confirm that the helm files are downloaded correctly. The issue seems to be that the file is not set as executable.
I have raised an issue on MS developer community (https://developercommunity.visualstudio.com/t/Helm-tool-installer-recently-started-fai/10221504?space=21&sort=newest) and will update any feedback I receive.
As a workaround, I have found that using the HelmInstaller#1 (along with KubectlInstaller#0 where necessary) has allowed me to get my pipeline working again.
We've had the same issue today morning and we fixed using HelmInstaller#1 Preview and also we needed to add a new task for Kubectl Tool Installer.
With that our pipelines were fixed.
Related
I am using the VSTFS CI/CD pipeline to automate my .NET Core 5.0 with Angular 12 web application.
It failing the build at Publish step (see below screenshot) with error:
'npm' is not recognized as an internal or external command,
2021-12-13T20:19:46.9855025Z operable program or batch file.
2021-12-13T20:19:46.9917349Z D:\TFSBuildAgent\_work\58\s\src\WebUI\WebUI.csproj(85,5): error MSB3073: The command "npm install" exited with code 9009.
2021-12-13T20:19:47.0482106Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2021-12-13T20:19:47.0496257Z ##[error]Dotnet command failed with non-zero exit code on the following projects :
What could be the issue?
Thanks
It looks like npm is not found by the agent. Make sure Node is installed globally on the machine and npm has been added to the system wide path environment variable.
Or add the Node Tool Installer task to your workflows.
I fixed the issue by deleting the npm publish tag in WebUI project file.
I have recently upgraded some of our windows application to VS2019 and created the setup project using VSInstallerProject extension in VS2019 . What I noticed is setup is not getting created when the Release pipeline is run , but I need the msi (or exe) files here so I can use the same to install on app server .
I have made changes in my pipeline and added a task : 'DutchWorkz - Build VS Installer(s)' in the release pipeline .
I have attached the logs of the error I am getting at this task in Azure Devops below .
Build is getting failed at this task .
Can anyone guide me on what the issue here is and how can I resolve it ?
Also , I want to create the setup projects/msi in VS2019 , but I don't see Vs2019 option in this task,
how can I use this task in VS2019 version .I have Vs2019 installed on agent server .
2020-09-21T20:04:43.3394997Z ##[section]Starting: Create .msi file(s) from VS Installer project(s).
2020-09-21T20:04:43.3539534Z ==============================================================================
2020-09-21T20:04:43.3539958Z Task : DutchWorkz - Build VS Installer(s)
2020-09-21T20:04:43.3540023Z Description : Build .msi file(s) from VS Installer project(s).
2020-09-21T20:04:43.3540076Z Version : 1.2.4
2020-09-21T20:04:43.3540129Z Author : DutchWorkz B.V.
2020-09-21T20:04:43.3540201Z Help : <b>BuildVsInstaller v1.2.4</b>, DutchWorkz B.V. (Robin Paardekam)<br/><br/>Visual Studio Installer projects are not supported by MSBUILD, so a regular build will not generate your installer files (.msi). Use this build-task to build the .msi file(s) for your project by running devenv on the buildagent directly. <br/><br/><b>Dependencies:</b><br/>Dep1: when using VisualStudio 2017, this task will only function properly if you installed it in the default C:\Program Files (x86)\ location.
2020-09-21T20:04:43.3540311Z ==============================================================================
2020-09-21T20:05:07.5667900Z DEBUG: Aggregated: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com
2020-09-21T20:05:07.5714835Z Now running (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com) with Arguments ("D:\VSTS Agent Folder\SO\6\s\SOApplications.sln" /Build "release|any cpu" /Project "D:\VSTS Agent Folder\SO\6\s\App_Tool_Installer\App_Tool_Installer.vdproj" /Out "D:\VSTS Agent Folder\SO\6\b\BuildInstaller_Log_20200921200507.txt")
2020-09-21T20:05:15.0213322Z Done running DevEnv process. Success = False.
2020-09-21T20:05:15.0238151Z ##[error]Unable to process command '##vso[task.addattachment type=Distributedtask.Core.Summary;name=Installer project errors;]D:\VSTS Agent Folder\SO\6\b\BuildInstaller_Log_20200921200507.txt' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
2020-09-21T20:05:15.0239574Z ##[error]Cannot upload task attachment file, attachment file location is not specified or attachment file not exist on disk
2020-09-21T20:05:15.1116369Z Attachment added: Log file for Installer generation.
2020-09-21T20:05:15.1928578Z ##[error]An error occurred while running DevEnv! Please review logfile BuildInstaller_Log_20200921200507.txt
2020-09-21T20:05:15.2720322Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
I have tried using devenv command line too , inorder to build the setup project .I have tried it with both the vs2017 (professional) and vs 2019(enterprise) and I am getting issue in both .While issue with 2017 is about license , I am not able to figure out what's causing the issue for 2019 . Please let me know if you have any thoughts on what could possibly be causing this issue and how can this be resolved . The goal is offcourse to build the setup project with azure devops pipeline and use the generated msi file for installation on app server .
Thanks in advance .
Here's the screenshot for new build and issue :
Build agent server has Vs installer already installed , pls see if this is okay :
Please check the new logs from 'command line task' below :
2020-09-26T16:04:39.7854210Z ##[debug]Evaluating condition for step: 'Command Line Script'
2020-09-26T16:04:39.7856182Z ##[debug]Evaluating: succeeded()
2020-09-26T16:04:39.7856654Z ##[debug]Evaluating succeeded:
2020-09-26T16:04:39.7857594Z ##[debug]=> True
2020-09-26T16:04:39.7858101Z ##[debug]Result: True
2020-09-26T16:04:39.7858600Z ##[section]Starting: Command Line Script
2020-09-26T16:04:39.8082090Z ==============================================================================
2020-09-26T16:04:39.8082357Z Task : Command line
2020-09-26T16:04:39.8082602Z Description : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
2020-09-26T16:04:39.8082847Z Version : 2.164.2
2020-09-26T16:04:39.8083025Z Author : Microsoft Corporation
2020-09-26T16:04:39.8083274Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
2020-09-26T16:04:39.8084133Z ==============================================================================
2020-09-26T16:04:39.8097829Z ##[debug]tf vc resolvePath $\CDM\Dev /loginType:OAuth /login:.,*** /noprompt
2020-09-26T16:04:40.1991127Z ##[debug]D:\VSTSAgent\sn\30\s
2020-09-26T16:04:41.0198149Z ##[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352
2020-09-26T16:04:41.1044331Z ##[debug]Entering D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\cmdline.ps1.
2020-09-26T16:04:41.1126277Z ##[debug]Loading resource strings from: D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\task.json
2020-09-26T16:04:41.1272687Z ##[debug]Loaded 6 strings.
2020-09-26T16:04:41.1306950Z ##[debug]SYSTEM_CULTURE: 'en-US'
2020-09-26T16:04:41.1325343Z ##[debug]Loading resource strings from: D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\Strings\resources.resjson\en-US\resources.resjson
2020-09-26T16:04:41.1467074Z ##[debug]Loaded 6 strings.
2020-09-26T16:04:41.1670941Z ##[debug]INPUT_FAILONSTDERR: 'false'
2020-09-26T16:04:41.1696717Z ##[debug] Converted to bool: False
2020-09-26T16:04:41.1718695Z ##[debug]INPUT_SCRIPT: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv" "D:\VSTSAgent\sn\30\s\st.sn.ComponentManagement.sln" /build release'
2020-09-26T16:04:41.1739155Z ##[debug]INPUT_WORKINGDIRECTORY: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.1861366Z ##[debug]Asserting container path exists: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.1900763Z Generating script.
2020-09-26T16:04:41.1963727Z Script contents:
2020-09-26T16:04:41.1969048Z "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv" "D:\VSTSAgent\sn\30\s\st.sn.ComponentManagement.sln" /build release
2020-09-26T16:04:41.2078510Z ##[debug]AGENT_VERSION: '2.173.0'
2020-09-26T16:04:41.2148233Z ##[debug]AGENT_TEMPDIRECTORY: 'D:\VSTSAgent\sn\_temp'
2020-09-26T16:04:41.2166134Z ##[debug]Asserting container path exists: 'D:\VSTSAgent\sn\_temp'
2020-09-26T16:04:41.2329780Z ##[debug]Asserting leaf path exists: 'C:\Windows\system32\cmd.exe'
2020-09-26T16:04:41.2337995Z ========================== Starting Command Output ===========================
2020-09-26T16:04:41.2446509Z ##[debug]Entering Invoke-VstsTool.
2020-09-26T16:04:41.2539207Z ##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "D:\VSTSAgent\sn\_temp\442cb1cb-a43b-4d2a-b036-4f16ab588410.cmd""'
2020-09-26T16:04:41.2553937Z ##[debug] FileName: 'C:\Windows\system32\cmd.exe'
2020-09-26T16:04:41.2568488Z ##[debug] WorkingDirectory: 'D:\VSTSAgent\sn\30\s'
2020-09-26T16:04:41.2608339Z ##[command]"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\VSTSAgent\sn\_temp\442cb1cb-a43b-4d2a-b036-4f16ab588410.cmd""
2020-09-26T16:04:47.9474432Z
2020-09-26T16:04:47.9514773Z Microsoft Visual Studio 2019 Version 16.7.3.
2020-09-26T16:04:47.9656002Z Copyright (C) Microsoft Corp. All rights reserved.
2020-09-26T16:04:47.9656269Z
2020-09-26T16:04:47.9656416Z The license for Visual Studio expires in 19 days.
2020-09-26T16:04:47.9656554Z
2020-09-26T16:04:47.9657872Z Some errors occurred during migration. For more information, see the migration report:
2020-09-26T16:04:47.9658144Z D:\VSTSAgent\sn\30\s\UpgradeLog2.htm
2020-09-26T16:04:50.0902169Z 1>------ Build started: Project: st.sn.ComponentManagement, Configuration: Release x86 ------
2020-09-26T16:04:52.8763939Z ========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
2020-09-26T16:04:53.4375608Z ##[debug]Exit code: 0
2020-09-26T16:04:53.4417000Z ##[debug]Leaving Invoke-VstsTool.
2020-09-26T16:04:53.4426510Z ##[debug]Leaving D:\VSTSAgent\sn\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.164.2\cmdline.ps1.
2020-09-26T16:04:53.5245394Z ##[section]Finishing: Command Line Script
Here's the additional error log :
EVEN though the command line task passed , the .vdproj setup project didn't get updated or build . I can see that from timestamp , all other projects getting updated as usual .
I found a similar ticket you can refer to it.
Configure self-hosted agent and make sure the VS Installer Projects extension is installed on your own build agent and then you can build the setup project either use command line task with "devenv" or use the "Build VS Installer" task.
If you get the error like 8000000A, you can follow the instruction here to configure your self-hosted agent: Solution: An error occurred while validating. HRESULT = '8000000A'.
By the way, since this extension is developed by a third party. You can connect the extension owner to get the detail info
Update1
We can install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
I looked at the package you mentioned, at this location - https://marketplace.visualstudio.com/items?itemName=dutchworkz.BuildInstaller&ssr=false#review-details
If you go there and look at the comments other users have left behind, the error is something that is present as part of the build process. The original developer has not fixed it.
At the same, just like the users have mentioned, you are able to see the msi installer and use it. So, you are (I am assuming) getting what you need, the installer.
My best suggestion is, since you are getting what you need, ignore the error and wait till the developer fixes this issue. Until then, there is nothing you or anybody else can do about it.
Note : I also noticed that if you are using the default configuration during the build process for simple projects, it works fine. Your project and build may have some customization which is where other users have reported errors.
Over the night all our builds and releases pipelines failed due to introducing the new Helm Install task or 3.0 Helm release. We manage to fix Helm install by using the *1 version in preview and install last working helm which was 2.16.0. After that our task Heml Init failed because it cannot find the kubectl. Yesterday everything was working fine. This is happening across our all builds and releases. Directory in which it trying to find kubectl is empty for some reason. Did something changed over the night?
Log:
2019-11-14T10:22:21.1487212Z ##[debug]Kubeconfig file path: C:\agent\_work\_temp\helmTask\1573726941144\config
2019-11-14T10:22:21.1494250Z ##[debug]which 'kubectl'
2019-11-14T10:22:21.1574073Z ##[debug]not found
2019-11-14T10:22:21.1576552Z ##[debug]task result: Failed
2019-11-14T10:22:21.1634103Z ##[error]Error: Unable to locate executable file: 'kubectl'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.
2019-11-14T10:22:21.1641140Z ##[debug]Processed: ##vso[task.issue type=error;]Error: Unable to locate executable file: 'kubectl'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.
2019-11-14T10:22:21.1642296Z ##[debug]Processed: ##vso[task.complete result=Failed;]Error: Unable to locate executable file: 'kubectl'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.```
The solution was to add checkLatestHemlVersion to false:
- task: HelmInstaller#0
displayName: 'Install Helm 2.16.1'
inputs:
helmVersion: 2.16.1
checkLatestHelmVersion: false
As of now, since Azure Kubernetes supported version was set to 1.23.12, you should use version 1 in Azure Release Pipeline which is relevant for new k8s environment
How to run .AppImage on ubuntu 17.10?
I did cura-build from the following exec (AppRun and Appimagetool) files from https://github.com/AppImage/AppImageKit/releases
~cura-build/build$ make
Copying AppRun executable...
...
...
...
...
...
Embedding ELF...
Marking the AppImage as executable...
Success
Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io
[ 98%] Built target packaging
Scanning dependencies of target signing
[100%] Signing Package...
Generating signature...
Generating SHA-1 sum...
[100%] Built target signing
After generated package I got an .Appimage file, then I try to run this file,
~: chmod a+x Cura-0.0.0-master.AppImage
~: ./Cura-0.0.0-master.AppImage
execv error: No such file or directory
I checked with these file properties as 'Allow executing file as program'
How to resolve this?
Please download a readymade AppImage from https://ultimaker.com/en/products/ultimaker-cura-software and report issues at https://github.com/Ultimaker/Cura/issues, thanks.
for RUN
in linux(ubuntu)
chmod +x Name.AppImage
./Name.AppImage
Context
We are trying to use edeliver to deploy a "Hot Upgrade" of a Phoenix Web Application to a remote Virtual Machine instance.
Our aim is to build an "upgrade" version of the app each time so that the app can be "hot" upgraded in production without any down-time.
We have succeeded in doing this "hot upgrade" on a "Hello World" phoenix app:
https://github.com/nelsonic/hello_world_edeliver which is automatically deployed from Travis-CI when the build passes. see: https://travis-ci.org/nelsonic/hello_world_edeliver/builds/259965752#L1752
So, in theory this technique should work for our "real" app.
Attempting to Deploy a "Real" Phoenix App using Edeliver
Ran the following command (to build the upgrade):
mix edeliver build upgrade --auto-version=git-revision --from=$(git rev-parse HEAD~) --to=$(git rev-parse HEAD) --verbose
i.e. "build the upgrade from the previous git revision to the current one"
So far, so good. "Release successfully built!"
Error: vm.args: No such file or directory
When we attempt to deploy the upgrade:
mix edeliver deploy upgrade to production --version=1.0.3+86d55eb --verbose
cat: /home/hladmin/healthlocker/releases/1.0.3+86d55eb/vm.args: No such file or directory
Note: we have a little bash script that reads the latest upgrade version available in .deliver/releases and deploys that see: version.sh
Question:
Is there a way to ignore the absence of the vm.args file and continue the deployment?
Or if the file is required to complete the deployment, is there some documentation on how to create the file?
Note: we have read the distillery "Runtime Configuration" docs: https://github.com/bitwalker/distillery/blob/master/docs/Runtime%20Configuration.md and are sadly none-the-wiser ...
Additional Info
Environment
Localhost: Mac running Elixir 1.4.2
Build Host: Ubuntu 16.04.2 LTS running Elixir 1.4.5
mix.exs file: https://github.com/healthlocker/healthlocker/blob/continuous-delivery/mix.exs
edeliver version: 1.4.4
Build tool: distillery version: 1.4.0
Umbrella project: yes.
This question was also asked on: https://github.com/edeliver/edeliver/issues/234
As mentioned by others, the vm.args file is necessary for BEAM to run the release. A default file is created by distillery during the release build process and should be located in releases/<version>/vm.args. From your log output it looks like expected directory is being checked.
Can you show us the contents of /home/hladmin/healthlocker/releases/?
Can you confirm that the default vm.args file is being created when building the release and extracting it (outside of the upgrade process)?
You also asked:
Or if the file is required to complete the deployment, is there some documentation on how to create the file?
If diagnosing the problem with the default vm.args file doesn't get you anywhere, you can also write your own file and configure distillery to use that file instead of the default. The details for this are in the distillery configuration docs. In short,
add the vm_args setting to your distillery config, which should be at rel/config.exs(relative to your project root), for example:
environment :prod do
set vm_args: "<path>/vm.args"
[...]
end