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
Related
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.
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.
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
When running mix edeliver version production locally it fails with the following output
EDELIVER MYAPP WITH VERSION COMMAND
-----> getting release versions from production servers
production node:
user : app_user
host : my_app
path : /home/app_user/my_app.io
response: bash: line 4: bin/my_app: No such file or directory
bash: line 47: bin/my_app: No such file or directory
VERSION DONE!
The error is obvious, as the executable lives in: ~/my_app.io/my_app/_build/prod/rel/my_app/bin
I'm also unable to run any of the start/stop/restart etc commands
The deployment was successful because when I ssh in, and run the start command it works.
I would like to know if anyone can point me in the direction of some config parameter that I'm missing, as the local commands are a lot more efficient.
Figured out the problem
I only built my app by running the following: env MIX_ENV=prod mix edeliver build release
I was probably too excited and forgot to actually deploy the release using something similar to the following mix edeliver deploy release to production --version=0.0.1
Hope someone else might benefit from this also.