Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Jenkins Output Parsing #520

Closed
Iristyle opened this Issue Nov 10, 2012 · 3 comments

Comments

Projects
None yet
3 participants

While I would like to see a more official stance on this, I understand you don't want to use a standard log library or similar per #20

The reason this is important, is because

  • Not all plugins produce output that can be consumed easily by Jenkins.(ideally tools you want to analyze the output of have some JSON / XML format that Jenkins understands natively or via plugin)
  • Jenkins has a Log Parser Plugin -- This thing is an oldie but a goodie.. and can scrape build output and turn that into warnings / errors based on regex. This can be used to not only fail the build, but it has a UI that will take you right to the broken spot in the log -- saves a lot of time.

So with that in mind, I'd like to suggest adding something to the Wiki or docs.

This is the file I'm using to define the rules in Jenkins

# Grunt Error
error /.*\.\.\.ERROR$/

# Grunt Warning
warning /^Warning: /

Krinkle commented Nov 28, 2012

Doesn't the exit code already provide this kind of boolean status?

That said, I would be very useful if for example grunt-contrib-jshint could optionally write --checkstyle-reporter output to file for Jenkins to consume. it is kind of annoying to always have to be forced to the console output in Jenkins when it has loads of useful presentational features.

IMHO, an exit code pass / fail isn't good enough for any non-trivial builds.

I want to be able to drill in and see precisely what's breaking my build easily w/out scanning through reams of text.. this of course, is what Jenkins is really good at (as long as the tools provide machine friendly output). I also want as much trending info that I can get my hands on, and just scraping stdout generally won't give you that kind of data.

At this point, in Grunt's case, it mostly comes down to how plugins surface warnings and errors. I can make it work with the above, which is why I think it should go into the wiki / docs at the very least. However, it would be nice if this was a little more standardized. Some plugins unfortunately do their own thing (and don't produce anything Jenkins can consume), so it seems a little silly to have to generate a bunch of regexs... If Grunt recorded calls to its warning / error reporting facilities, for instance.. it could dump out something that had the counts / reasons / etc.

But yeah, I agree it's annoying to have to fall back to anything that involves parsing stdout type output... sometimes it ends up being a necessary evil.

Owner

cowboy commented Dec 31, 2012

For now, utilizing the exit code plus ad-hoc parsing should do everything a user needs. In the future, we're going the use of a custom logger, which will let someone create custom reporters, etc.

@cowboy cowboy closed this Dec 31, 2012

@Iristyle Iristyle referenced this issue in gruntjs/grunt-contrib-jshint Mar 30, 2013

Closed

readability of JSHint output #31

samccone pushed a commit to samccone/grunt that referenced this issue Jul 24, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment