We're having issues with our automated deployment system.
On our own computers, running ng build generates the dist folder. Within the folder, it has the assets as expected.
I have replicated this, on the build server, manually pulling the git repository, and running the "build file" (the build server runs on Windows Server. The build and deploy process is managed via a PowerShell script for convenience).
When our Jenkins server runs the build script, the assets folder is missing from the /dist/ folder, as well as some other files configured in angular.json.
It is also not properly compiling the stylesheets, which I've believe is due to the same root cause.
The issue persists when running the PowerShell script directly from the Jenkins workspace when the shell is run as a system administrator.
The CLI does not produce any errors.
I'm attaching a verbose log, in case this could be helpful.
https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-output-txt
Running the script as the system administrator I've ruled out it being a permissions issue. Jenkins is also managing to create other files, such as the
.js files, and the index.html fine.
My workaround right now is to, via the deploy powershell script, to manually copy the assets folder, how-ever I'd love to get rid of this workaround as we're starting to get multiple files in our angular.json > assets section.
For references:
angular.json https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-angular-json
deploy script: https://gist.github.com/cf-jola/6cc6cff138da5105f3b10adffb72895f#file-deploy-ps1
Its a bug, in either Node or Angular CLI.
Because we have brackets, ( & ), in the build path, they get encapsulated in square brackets.
This causes the path: C:\Program Files (x86)\Jenkins\... to become this C:\Program Files [(]x86[)]\Jenkins\... and thereby become invalid.
We discovered the issue by using Process Monitor and looking over the events generated during the build process.
We are trying to build a c# app that has gulp do some of the bundling/minification for the front end website.
We are currently using node 6 because of gulp dependencies. A future branch is updating to node 10 but that requires different node dependencies as we migrate our project. I thought using a docker container for the build might help alleviate switching between node versions on our local machine.
So I created a docker image
FROM microsoft/dotnet-framework:4.7.2-sdk
Then I loaded npm on top of it. Binding a volume to my source directory I'm able to install npm packages, install nuget packages and call build but it will fail because it is missing my gulp step.
I have gulp installed both globally in the container and locally in the node_modules folder. I end up with an error like,
C:\Program Files\node\node-v6.16.0-win-x64\node_modules\gulp\node_modules\sver-compat\sver.js:19
var semver = version.match(semverRegEx);
^
TypeError: Cannot read property 'match' of undefined
at new Semver (C:\Program Files\node\node-v6.16.0-win-x64\node_modules\gulp\node_modules\sver-compat\sver.js:19:23)
at Function.match (C:\Program Files\node\node-v6.16.0-win-x64\node_modules\gulp\node_modules\sver-compat\sver.js:374:15)
I have search all over the web for multiple days with no luck finding anything that can help me with what is blowing up here. Has anyone been able to get gulp to run successfully inside of a Windows Server Core docker container? Is the problem with the directory being mounted? Using Docker for Windows if that matters here.
On Windows-Server-Core the best I can surmise there is an issue with docker, volume-mounts and npm/gulp system links.
I believe the user set on the container by default wants to use the c:\containermappeddirectories folder. I am not sure at this point if that is configurable.
But my work around looked like this in powershell all running in the container,
npm install -g gulp#^3.9.1
md c:\ContainerMappedDirectories
cd c:\containermappedDirectories
robocopy /S "c:\MyUISource" C:\ContainerMappedDirectories
npm install #installs gulp locally to this folder
gulp prod-build
robocopy /S C:\ContainerMappedDirectories\dist c:\MyUISource
So I installed gulp globally, I created the local workspace copied my source in and ran npm/gulp then copied back my output to the mounted location.
In the end it was the best work around I could accomplish to complete my task.
TLDR:
I have a Grails 3 project. The run-app command was working fine. Then I checked it into Perforce. Now run-app fails.
DETAILS:
Grails Version: 3.1.1
Groovy Version: 2.4.5
JVM Version: 1.8.0_91
Gradle 2.13
% grails clean
BUILD SUCCESSFUL
% grails run-app
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':processResources'.
Could not copy file '/Volumes/Neo/singram/work/code/depot/dvdco/webapplications/nightcrawler/grails-app/i18n/messages.properties' to '/Volumes/Neo/singram/work/code/depot/dvdco/webapplications/nightcrawler/build/resources/main/messages.properties'.
GUESS at cause:
Perforce, when a file isn't checked out for editing, will make that file non-writable (chmod a-w). As best I can tell, run-app invokes gradle's processResources which successfully copies the file in question once, then seemingly attempts to copy it again during the same build cycle and fails because thew newly copied file is not writable so it cannot be overwritten with a copy of itself.
WORK-AROUND
The run-app command succeeds if I check out the whole project for editing first. Don't really want to have to do this as it introduces opportunity for error during check-ins.
QUESTION:
Is there a better way than my work-around? Why is gradle's processResources copying the same files more than once? Is there some sort of hook into processResources or run-app that I can use to "chmod -R u+w build" ?
A couple of options, methinks. Either 1) change the filetype(s) (if Perforce-controlled) to +w to make them writable; or 2) change the workspace spec to include the "allwrite" option to make all files writable. –
In jenkins iam facing an error when i trigger the gradle task.
When i execute the below shell
cd /home/cucumberBdd
./gradlew cucumber
I got this error ".gradle/1.8/taskArtifacts/cache.properties.lock (Permission denied)"
Below are the configurations:
Os-Ubuntu
CI-Jenkins
Buildtool:Gradle
Script: gradle script
I have installed and mentioned the gradle version in the manage jenkins.
One thing which i noticed is in jenkins the above command + whoam i gives jenkins name but the project folder writes are with system user.Can anyone tell me please how to avoid this error
You should not put .gradle in the version control at all, only the gradle directory (without the dot) needs to be versioned. Everything in .gradle is just caching stuff and can be safely deleted and recreated.
I've installed the Gradle plugin for Jenkins. When I try to build the project I get the following error:
[workspace] $ gradle clean -b build/build.gradle
FATAL: command execution failed
java.io.IOException: Cannot run program "gradle" (in directory "/Users/Shared/Jenkins/Home/jobs/test/workspace"): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:707)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$ProcStarter.join(Launcher.java:345)
at hudson.plugins.gradle.Gradle.performTask(Gradle.java:201)
at hudson.plugins.gradle.Gradle.perform(Gradle.java:97)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1404)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:53)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:453)
... 16 more
Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure
Finished: FAILURE
Running the task $ gradle clean -b build/build.gradle from the command line works as expected.
I had the same issue and found that the problem for me was the gradle version in the project configuration. It was set to Default and when I set it to the gradle version I was pointing to in the plugin configuration in the Manage Jenkins > Configuration Options, It found gradle and worked properly.
This is a difficult issue to debug and I hope this saves someone else some time.
Solution Mastering_the_Object pointed out worked form me too, just to clarify steps there:
just installing Gradle plugin in Jenkins is not enough, you must also go to:
Jenkins->Manage Jenkins->Configure Jenkins->Configure system.
Under "Gradle Installations" type in name (it appears as version in project configuration), check "Install automatically" and select version. Then you can select that "Gradle version" in project configuration.
I was getting this error using the Gradle wrapper, was able to fix my broken build as follows:
Go to Manage Jenkins -> Global Tool Configuration -> Gradle -> Add Gradle, give it a name
Go to Jenkins -> (your job) -> Configure -> Build, choose "Invoke Gradle" and change the Gradle version from (Default) to the named version
When running Gradle on a CI machine such as Jenkins, it's most convenient to use the Gradle Wrapper.
On your development machine, stand in your root project directory and run
gradle wrapper
Then, check in the resulting files into your source control system. After that, you don't have to install anything on your Jenkins server if you need to change Gradle versions. Just configure your Jenkins job like this:
Quoting from the Gradle User Guide:
By distributing the wrapper with your project, anyone can work with it
without needing to install Gradle beforehand. Even better, users of
the build are guaranteed to use the version of Gradle that the build
was designed to work with. Of course, this is also great for
continuous integration servers (i.e. servers that regularly build your
project) as it requires no configuration on the server.
The jenkins can not find the gradle executable. I have never made gradle wrapper to work. Please follow the following steps:
Download gradle ( http://gradle.org/downloads),
unpack it to, e.g., /usr/local/lib/gradle ,
open /etc/profile and add the following two lines:
export GRADLE_HOME=/usr/local/lib/gradle
export PATH=$PATH:$GRADLE_HOME/bin
It works for my jenkins installation.
ps. I answer this old question, because it is a common issue when setting up gradle with jenkins. I have spent some time trying to make the gradle wrapper work without success before.
Used both #Skarab & a number of other solutions here to get it to work.
Download gradle ( http://gradle.org/downloads),
unpack it to, e.g., /usr/local/lib/gradle ,
open /etc/profile and add the following two lines:
export GRADLE_HOME=/usr/local/lib/gradle
export PATH=$PATH:$GRADLE_HOME/bin
Then under Manage Jenkins > Configure system > Gradle, defined GRADLE_HOME and gave that gradle installation a name
Then, {this could be a bug} for the project, change gradle version from Default to the one I defined above
As others have noted, this is because Jenkins can't find the gradle executable.
None of the published solutions worked for me, but I was able to fix the problem by adding the gradle bin dir to the path set in the .bashrc for the build account on the build slave. Modifying the .profile failed, and setting PATH in the jenkins node configuration also failed.
Some posts will suggest setting the gradle path in the tools menu, but no gradle entry was available there either (perhaps due to regressions / design changes in the gradle plugin?).
In any case, the best test I found (short of running the build again and watching for failure) was to run env over ssh:
ssh <host> env
and check the PATH variable defined that way; if gradle isn't in that path, you probably won't be able to run it from jenkins.