When running a sh-command inside of a jenkins pipeline, the commands themselves are not running.
The shell is part of my PATH-variable, thus the cmd-prompt is running, but the commands are not.
Code inside pipeline:
sh "echo Hello World"
bat "echo Hello World"
Result:
[Pipeline] sh
Microsoft Windows [Version 10.0.18362.657]
(c) 2019 Microsoft Corporation. Alle rechten voorbehouden.
C:\Program Files (x86)\Jenkins\workspace\testCI>
[Pipeline] bat
C:\Program Files (x86)\Jenkins\workspace\testCI>echo Hello World
Hello World
How do I get the sh-commands to run?
I'd rather not rely on bat, as this pipeline (and jenkins-workspace) will be moved to a UNIX-environment in the future
Try installing either git bash or cygwin. Sh and Bash executables come by default with them.
You can use path to that sh file here.
Since it's a Windows 10 agent, I recommend installing a Linux subsystem since you plan on moving to a similar environment in the future. However, this would require you to reinstall Jenkins in that subsystem, but it would behave how it would on any other UNIX system out of the gate without having to configure and manage third-party software that is not guaranteed to work on Windows (with Jenkins) as it does on UNIX systems.
You can install a new Jenkins master on the Linux subsystem while keeping the Windows master intact, and then migrate users over when it is configured the way you want it to be.
Installing WSL
https://learn.microsoft.com/en-us/windows/wsl/install-win10
Related
When running the command bash or ubuntu in PowerShell, the Windows-Subsystem-for-Linux is entered, however, the current working dir for PowerShell is not carried across to BASH. Is there a way to implement this functionality?
From your Windows Powershell or Powershell Core window, type bash (or wsl); for example:
Now, later versions of Windows include WSL.exe, which replaces bash.exe. The behavior of both executable is the same on my system. The official documentation for wsl.exe states:
You can read that documentation here. Net-net,
I'm running Windows 10 Build-17763. If you aren't experiencing the same behavior I am, you might be running an older version of WSL. You can determine the version of WSL from your build number.
I'm new to PowerShell, so this may be a basic oversight.
On windows 10 pro (for development) and Windows Server 2016 (target environment) I have installed the latest released version of PowerShell.
(Get-Host).Version gives Major 6, Minor 1, Build 0, Revision -1.
My first mistake? as a version of PowerShell is already installed by default?
The process I am trying to automate is to share a backup cartridge drive from host physical machines, and access it as a network share for the VMs (Hyper-V) to backup to. In development I'm just using a USB attached drive, but errors are the same in both environments.
I keep getting errors in any of the SMBShare commands :
Get-SmbShare, Remove-SmbShare, New-SMBShare.
The errors are of the format:
"The term 'Get-SmbShare' is not recognized as the name of a cmdlet,
function, script file, or operable program"
I am running Powershell as administrator, and getting the same errors when typing directly, or from running a script.
Is there something I need to add/import to use SMBShare commands ?
PowerShell has fractured; everything up to v5.1 was Windows only, then v6 was made cross-platform by moving it to a new foundation, and that lost a lot of compatibility.
Your easiest way forward is to use PowerShell 5.1, unless you need v6 for some specific feature. Or to use 6 to launch 5.1 and run a script, the same way you might launch Python or VBScript engines to run a script.
But if you are staying with 6, then there is another option - Microsoft have released a WindowsCompatibility Module - still an early release candidate, so not heavily tested. This brings a way to run Windows modules inside PS v6 (only on Windows, not cross platform).
You would need to install it, with this as an administrator:
Install-Module WindowsCompatibility
Then you can:
Import-Module WindowsCompatibility
Import-WinModule SmbShare
Get-SmbShare
I've two Windows machines and both have bash installed. However, they differ in the way bash starts up:
Machine 1:
Typing "bash" starts the bash. Then I can type commands like ls.
Machine 2:
It seems like it starts bash and directly runs ls in it, by only typing "ls". After that it switches back to CMD automatically, like this:
Does anyone know which setting enables the behavior of machine 2? Everything looks the same for me. It's a nice feature and I want to enable it on machine 1 as well.
Bash on Ubuntu on Windows executables (binaries) cannot run from Windows applications such as cmd.exe or PowerShell.exe - Windows doesn't even see them as executable.
The likeliest explanation is that you've installed a separate Unix emulation environment such as GnuWin, which comes with native Windows binaries.
To see the location of your - by definition Windows-native - ls executable, run where ls, which will probably tell you what product it came with, such as
C:\Program Files (x86)\GnuWin32\bin\ls.EXE.
Note that the Ubuntu on Windows binaries are stored in a user-specific manner in
%LOCALAPPDATA%\lxss\rootfs\bin, but that is a moot point, given that you cannot invoke them from Windows.
In Windows 10, there is a built-in Linux subsystem (one of the greatest features of Windows 10). It gives you almost a complete Linux shell for various distributions, and you can almost do anything with it (user mode).
I bet it is installed on your first computer, and you are using that subsystem. In the latest version of this subsystem, you can run both Linux executables and Windows exe files.
I'm currently setting up a Jenkins server on Windows 10, in the hope of being able to make the build scripts more cross platform I was hoping to take advantage of the bash environment that is available in Windows 10.
I hoped this could be done just by setting the path to the shell in Jenkins to be the bash executable, however I've encountered some problems with trying to get this to work.
Firstly when I set the path to be C:\Windows\System32\bash.exe but Jenkins didn't seem to be able to see this path.
I assumed this was because Jenkins was running as 32-bit and changed the path to be C:\Windows\sysnative\bash.exe but when I try and use this I get the error
[workspace] $ C:\Windows\sysnative\bash.exe -xe C:\Users\Jenkins\AppData\Local\Temp\hudson4346151084156392102.sh
Error: 0x80070005
Build step 'Execute shell' marked build as failure
I think I'm poking around in the dark a bit so I didn't know if anyone had any experience of trying to use the bash shell on Windows 10 within Jenkins?
The error 0x80070005 usually appears during Windows Update or by specific applications, because of the .DLL files permission being denied. Look at your permissions and then try again.
You can run this on Windows in order to execute a bash shell script:
bash -c /mnt/c/Users/$LOGNAME/Downloads/abc.sh
Make sure that the script is executable (chmod +x)
(Only works on Windwos 10 with a linux subsystem installed)
I recently started using the Windows Subsystem for Linux (WSL) to see if my Linux Makefile & arm-none-eabi-gcc based microcontroller project would build "natively" in Windows. To my surprise, the tool chain and Linux based development tools installed and worked perfectly on first go, without any modifications to the Makefile.
So that got me thinking to try doing all my code editing in Visual Studio using the IDE features while doing the actual build in the Linux & bash environment provided in WSL.
Unfortunately, when specifying a "Build Command Line" in the NMake options for my Visual Studio project, putting in "C:\Windows\System32\bash.exe build.sh" doesn't work because:
'C:\Windows\System32\bash.exe' is not recognized as an internal or external command,
operable program or batch file.
This is strange to me because I specified the full path and it couldn't find the WSL bash executable, and also attempting to add it as an "External Tool" doesn't seem to work because the executable doesn't show up in the selection window despite being able to see other executables in the same directory.
Some off topic opinion: If Microsoft can make Visual Studio and WSL work together seamlessly then I would likely switch from my Ubuntu virtual machine setup for a WSL based development environment.
Here's how you have to do it:
Nmake is not a 64-bit application, so when it tries to use Windows utilities and system32, WoW64 tricks it into looking in a different location.
The way you have to launch it from a 32-bit application is:
%windir%\sysnative\bash.exe
However, your command is also malformed. You will need to do it like this:
%windir%\sysnative\bash.exe -c "sh build.sh"
or maybe
%windir%\sysnative\bash.exe -c "./build.sh"
if DriveFS permissions allow execution.
otherwise it will attempt to execute build.sh as a command in your linux user's $PATH.
Source:
https://github.com/Microsoft/BashOnWindows/issues/870
This is what I have in my Build Command Line setting. It works fine.
start /WAIT %windir%\sysnative\bash.exe -c "cd /mnt/d/Projects/IoT/ESP8266/;./gen.sh -m DEBUG; read -n 1; exit;"