I'm running jenkins pipeline on a slave computer (slave run from agent command line - user with full admin privileges).
when trying to run a tool from system32 folder, it failes: The system cannot find the path specified.
if I copy the tool to c:\myfolder, it succeeds.
I've also tried to run msbuild - fails on post build regsvr32. but, when running the same command via computer's command line (not jenkins), it succeeds.
It looks like I have a problem with permissions but I do not know what is wrong. jenkins is running via command line with a user that have administrator permissions.
any ideas?
My jenkins is installed in C:\Program Files (x86)\Jenkins
bat file is located in C:\Users\Admin\workspace\demoWork\run.bat
When i run this bat file from cmd everything works fine. But when i try from jenkins executing batch command as mentioned in Image, Jenkins displays error as
Build step 'Execute Windows batch command' marked build as failure
Also inside jenkins folder automatically workspace folder gets created with Job title name. Can you guys please explain me in detail
Tatkal, you can't execute a command like in your image,
why don't you simply try
C:\users\admin\workspace\demowork\run.bat
or
call "C:\users\admin\workspace\demowork\run.bat"
"Also inside jenkins folder automatically workspace folder gets created with Job title name. Can you guys please explain me in detail" -
Jenkins creates folder with job title name automatically, saves jobs data and other build info... this is how it works. By default in jenkins job you can access your workspace using $WORKSPACE variable
You have put very little detail into this so I'm going by pure guess..
The Execute Windows batch command is to literally execute code, not execute a file.. to execute the file you could use this command :
start cmd.exe /c C:\myprj\mybat.bat
or you could take the contents of the .bat file and rewrite in in that command line..
The way Jenkins works is it creates its own workspace for each job, essentially to sandbox the environment, its a testing framework so it should be used to stage changes to code, which will then be pushed to your live(working) environment. People use it to automate some tasks, but this isnt the primary use of Jenkins.. if the above doesn't help you let me know more details of the error and I can try help you with it.
node {
bat 'D:\\gatling-charts-highcharts-bundle-3.0.2\\bin\\gatling.bat'
}
I'm using Gradle to build a java project.
When I run any task (assemble, test).
I get randomly an error :
Could not create service of type FileHasher using
GradleUserHomeScopeServices.createCachingFileHasher()
Did any one had the same issue before?
Gradle V:3.5
java 8
I'm using the java plugin.
Thanks,
I was facing the same because I accidentally hit ctrl+z during build, and then the error was the same as yours.
I tried to remove the lock file but it didn't solve the problem.
Then I find all the process related to gradle by ps aux | grep gradle, and then kill -9 <pid> them all. The build backed to normal.
In your terminal type this:
./gradlew build
and the outcome would be:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type FileHasher using GradleUserHomeScopeServices.createCachingFileHasher().
> Timeout waiting to lock file hash cache (/Users/zra/.gradle/caches/4.1-rc-1/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 17571
Our PID: 26055
Owner Operation:
Our operation:
Lock file: /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock
now do:
rm /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock
and build again.
P.S replace xxx with whatever username you've.
What worked for me was removing the lock file like suggested in the answer above: rm /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock and also killing the IDLE processes by running the command
./gradlew --status
It generates a list of gradle processes with status like
PID STATUS INFO
23580 IDLE 5.2.1
23860 IDLE 5.2.1
19058 STOPPED (stop command received)
Then kill one of the idle processes by kill <PID> and run the gradle build again.
One simple cause is that gradle daemon is not started with the same environment variable.
I had the same issue while changing the gradle user home.
Simply stop the daemon:
gradle --stop
change the ownership of .gradle/ using the following command:
sudo chown -R <USERNAME> .gradle/
I couldn't find this info elsewhere, posting in case it helps someone:
I had the same issue while running Android Studio on ChromeOS (on Chromebook).
I had shared a Google Drive folder with Linux (by selecting a folder, right-clicking and selecting Share with Linux) and created my project there. Build failed with this error, and removing the lock file did nothing for me.
Problem was resolved for me by re-creating the project under a 'Linux folder'.
If the OS is Windows.
Try this: gradlew build
Find de PID Process
And in CMD execute this command
TASKKILL /F /PID #PID
In my case, I was keeping the entire project in a folder managed by Google Drive Stream. Since that's a very rudimentary filesystem, Android Studio (or Git or Gradle, I can't tell which) was trying to do something on the FS that Google Drive Stream doesn't allow.
I simply moved the project onto my local drive and that fixed it!
I got the same error when I tried to execute ./gradlew from WSL2 ubuntu.
As suggested by #user16115, I stopped the running gradle in my host machine (windows machine) by issuing command gradlew.bat --stop.
After stopping the gradle in my host machine, I issued the same command ./gradlew in WSL2, gradle worked as expected.
ps: I have mounted my C:/ drive into WSL2 ubuntu.
This was same problem for me before some days and now only it's your or the user reading this solution.
Uninstall full android studio (means- 'after uninstall from control panel, delete folders of Android Studio,')
folders to be deleted:
C:\Program Files -> Android,
C:\Users{user folder name} -> .android & .gradle & {other folders related to Android Studio}
Reinstall form it's .exe and make sure your PC in connected with internet and with proper speed.
Download all SDK files as mention in that and keep downloading in Android Studio only. [do not download form other source- otherwise it will show errors, be careful]
Click on new project and select empty project and give the name and click on finish.
you will redirect to another window and than the main thing starts that is installation of GRADLE so for this you should have high connectivity of internet and that it will download automatically and and and now your are ready to go.
I had the same issue and the solution was to login with the correct user and then run gradle. I was logged in with a user that didn't had rights to run the tasks.
I just moved a project from Download folder (on Mac) to another one
If you try to build an inner project - try to go to root project and call
./gradlew <moduleName>:<command>
The easiest solution in my case wast to run
In case of linux
sudo ./gradlew bundleRelease
if windows then login with the user who has highest privileges.
Because this error occurred due to insufficient permissions
I want to copy binaries to stage server as the last step of build. Previously I was doing it for asp.net web sites powered by IIS. There were no problems as IIS doesn't block any boundaries. Now I need to do the same for executable server application (it executes some background tasks) which blocks at least its exe file. So I need somehow to close application, update binaries and then run application again.
What is the best way to achieve it using TeamCity?
I'm seems like your staging server is a windows machine. If that's the case, I'd recommend using two executables from the PsTools Suite (PsKill and PsExec) to kill/start your process. Here's how I would set everything up in TeamCity:
Download the PsTools Suite, and copy the contents of the zip file to a folder on the build server. I'll be using C:\Program Files\PsTools in my example.
Create a batch file that kills the executable server application, copies the appropriate binaries, and starts the application again. The batch file would look something like this:
"C:\Program Files\PsTools\PsKill" -accepteula \computername -u username -p password name_of_process_to_kill.exe
copy files - I'm assuming you copied binaries to your ASP.Net staging site using the command line. If not, I can provide more details later.
"C:\Program Files\PsTools\PsExec" -accepteula \computername -u username -p password -d "path_and_name_of_executable_on_remote_server" optional_commandline_args_here
Add a new command line build step to your TeamCity build configuration that executes the batch file created in step #2.
I hope this helps!
Here is how I solved it. I added Command Line step with following Custom Script:
taskkill /IM MyApplicationProcessName /F
xcopy RelativePathToBuildBinaires PathWhereToDeployBinaries /s /e /y
start PathToMyApplicationExeInDeployFolder
Initially it didn't work as TeamCity build agent worked as service (which do not have UI). Then I disabled service and started build agent as console (by TeamCityFolder/builagent/bin/agent.bat). And it worked.
Here is my problem:
I have a python build script building a .air package and deploying it on a server. If I run this script from a cmd.exe window, there is no problem, the files are correctly created and deployed.
But I would like to use Bamboo to be able to build my app everytime I commit/push changes. I configured it but have a serious problem: the .air package is created but the deployment (with a fabric script) doesn't finish... I noticed that the process is launched by 'Administrator' in a cmd.exe and by SYSTEM trough Bamboo. I think that this is the problem (maybe SYSTEM cannot find the ssh host or whatever), so I wanted to know if someone knows how to change the user executing the script to 'Administrator'.
Yes, you can change the user that your bamboo server runs as. I recently posted an answer with details on how do just that in Windows Mercurial global keychain . All the documentation for the windows stuff in the wrapper file can found at http://wrapper.tanukisoftware.com/doc/english/props-nt.html .