I am using visual studio task runner (2015) to run a Gulp task bound to before build.
I have set it up so that when the gulp tasks fails it sends exit code 1 and at the end it says "Process terminated with code 1." however the build continues.
This will cancel the build in team city so seems an issue linked Task Runner inside visual studio.
How can I prevent the build from taking place if it exits with a code other than 0?
You are correct in that this seems to be a Task Runner issue. The task runner does not communicate with MSBuild to stop a build if a BeforeBuild task fails.
To get around this, you can run your Gulp task via the project's pre-build event instead of via the Task Runner bindings.
Set the pre-build event
For class libraries, you can access Build Events by right-clicking your project and selecting Properties -> Compile -> Build Events....
For web projects, they are located at Properties -> Build Events.
Here is the command I used to call the Gulp task in pre-build event, which will prevent the MSBuild from running if it exits with a failure:
gulp -b $(ProjectDir) --gulpfile $(ProjectDir)gulpfile.js my-task
This command calls Gulp passing absolute paths for working directory and gulpfile.js.
Notes:
I found all kinds of context and working directory issues trying to use a more straight up command like gulp my-task.
$(ProjectDir) is one of the Macros for Build Commands.
It is assumed that Gulp is installed globally: npm install -g gulp. See jonas.ninja's answer for how to build this install into the command (or for an alternative that does not require the global dependency).
I implemented davidmdem's solution above and it was great... on my system. I had gulp installed globally, but one of my coworkers did not, so the pre-build event would fail. Running gulp from Task Runner Explorer uses the project-level gulp installation, but running gulp from the pre-build script uses the global gulp installation.
To prevent the situation where a new developer doesn't have gulp installed, I expanded davidmdem's pre-build script to the following:
(gulp --version || npm install -g gulp#3.9.0) & gulp -b $(ProjectDir) --gulpfile $(ProjectDir)gulpfile.js my-task
This command installs gulp (version 3.9.0 to match the project-level gulp installation) only if it is not already installed. Now gulp is not something that you have to think about before you can build the project!
(Update:)
An alternative (in my opinion: better) solution to this problem is to use npm as an intermediary. Continuing and modifying from the example above, I have a gulp task my-task that is being called from the command line. This removed the global gulp dependency and still properly stops msbuild if gulp fails.
Pre-build event:
npm run build
package.json:
"scripts": {
"build": "gulp min"
}
I have build fail for jshint with gulp working (well enough for me, maybe sufficient for others.) I imagine it may be extended to include all the tasks in Task Runner.
Here is what I used/did...
As per this page, I added/edited this in my project.json, which hooks into the prebuild event...
"scripts": {
"prebuild": [ "gulp default" ]
}
As per this page, I included the following for my jshint task...
// =============================
// jsHint - error detection
// =============================
gulp.task("jshint", function () {
var jshGlobals = [
'$',
'jQuery',
'window',
'document',
'Element',
'Node',
'console'
];
gulp.src([paths.jsFiles, norefs])
.pipe(jshint({
predef: jshGlobals,
undef: true,
eqnull: true
}))
.pipe(jshint.reporter('jshint-stylish'))
.pipe(jshint.reporter('fail'))
});
The latter two lines being the most significant. You will need to npm install jshint-stylish if you don't already have it.
Alternatively, for jshint-stylish, you can let VS handle it for you. Add the line for jshint-stylish as indicated below to your package.json...
{
"name": "ASP.NET",
"version": "0.0.0",
"devDependencies": {
"es6-promise": "~3.1.2",
"gulp": "^3.8.11",
"del": "^2.2.0",
"jshint": "~2.9.1",
"jshint-stylish": "~2.1.0",
"gulp-jshint": "~2.0.0",
"gulp-flatten": "~0.2.0",
"gulp-rename": "~1.2.2",
"gulp-cssmin": "0.1.7",
"gulp-uglify": "1.2.0",
"gulp-postcss": "~6.1.0",
"autoprefixer": "~6.3.3"
}
}
Which gives me this when there is an error (in addition to the failed build) which is sufficient for me to dig further if/as necessary...
As opposed to the more detailed error info I get when running the same task via command line or Task Runner...
I imagine this solution can be improved but figured I would share as I hadn't seen a whole lot about it elsewhere.
Cheers.
Related
What is the simplest way to tell cucumberjs to watch for source project files changes so that it can re-runs its tests?
You could add a gulp task. Here is more information on how gulp works https://gulpjs.com/docs/en/api/concepts
I'm trying to run a gulp watch when running my Java web-app with Gretty.
I'm using this plugin to run gulp from Gradle.
For the moment, I'm just able to run a single gulp build before the app run by doing this: appRun.dependsOn gulp_build
What I would like is that when I run the app, there is also gulp watch starting (task gulp_default in Gradle on my case), so that SCSS files are automatically compiled when I save them without having to restart the app.
I can't just do appRun.dependsOn gulp_build because gulp_default doesn't return anything, so the gradle task doesn't execute appRun.
Any idea how I can do this?
I found a way, but by using npm to start the app and not gradle.
I used the concurrently package. I start the app by doing npm start instead of gradle appRun, and I added this in my package.json:
"scripts": {
"start": "concurrently \"gradle appRun\" \"gulp watch\""
}
I am trying to generate tests report into teamcity, everytime built is made. I've researched the several methods and ended up finding Istanbul's teamcity reporter: teamcity
Now I am trying to integrate it into teamcity, but I've not found any instructions about it.
All you need to do is add a script target in your package.json that uses the reporter:
"script": {
...
"coverage:teamcity": "nyc --reporter=teamcity mocha ...etc..."
...
}
Then, in your build step, simply invoke it via command line npm run coverage:teamcity
Teamcity will automatically parse the output and generate the coverage summary for you.
I'm using gradle-node-plugin to help reduce dependencies for my project. Gradlew is basically replacing grunt or gulp in my project. This makes java my only dependency.
Before, I'd use npm run tsc and I had an npm task that would run tsc -w but now that npm is a gradle plugin, I can't call npm directly. I have the following task in my build.gradle:
task watch(dependsOn: 'npmInstall', type: NpmTask) {
outputs.upToDateWhen { false }
args = ['run', 'tsc']
}
Technically it works. It first makes sure that the npm plugin has installed all it's pieces (including typescript) and then will run my tsc task. The problem is that tsc -w never terminates. It watches my files for changes until I choose to terminate it. It does this successfully, but gradle constantly reports that the task is Building 75% > :watch. I have another task in package.json that offers up my files in an http-server and it behaves in the same way.
Is there a preferred way to have gradle run a never ending task like this or should I just let it think it's perpetually building?
This question is very specific to Bluemix DevOps.
I have a Java backend application that has a sizeable JavaScript front-end. So I created a GRUNT task to do the needed: uglify, minify, CDNify etc. My current setup is to have the Bluemix build just running mvn -B package and the Grunt task beforehand as a script on my local machine:
#!/bin/bash
grunt build
git add --all
git commit
git push origin master
But that precludes any edit using the online editor. So I'd like to have both task to run by the pipeline. I see 3 options:
Run both tasks in one build block triggered by git push as separate tasks
Run them in one build script triggered by git push
Run 2 pipeline steps, the first triggered by git push, the second by the completion of the first
something else
I haven't tried it yet (shame on me), just wanted to ask if someone did that before (If yes - cool, if no I will post my findings later on)
Solved it. This is what I tried:
modify the script in build and prefix with npm install npm or mvn (depends on what I selected) wasn't found)
add 2 jobs to one build stage, one grunt one maven (the deploy task would not find the war file)
Use 2 pipeline stages (see picture below) : Horray --- that worked.
None of the build steps required setting a directory, which is a little trap, since mvn sets target as default directory, so remove this. The script for Bower/Grunt is this:
#!/bin/bash
npm install
grunt build
the script for the maven task:
#!/bin/bash
mvn -B package
works like a charm (just be careful not to add npm modules you don't actually need, it slows the build quite a bit)