Got it. The catch was the configuration of the HTML publisher plugin (it can do more than I thought). I had to change the plugin config from: HTML directory to archive=target/jbehave/view Index page[s]=reports.html Report title=JBehave Reports Keep past HTML reports=true
to this: HTML directory to archive=target/jbehave Index page[s]=view/reports.html Report title=JBehave Reports Keep past HTML reports=true Previously only the "view" folder and its contents were being archived, however screenshots dir is at the same level as view so it wasn't being saved. Now I've bumped my archive dir up a level and provided a path to my Index Page (undocumented HTML plugin feature :)). Also, I no longer need to archive the artifacts using the native Jenkins archive artifacts, they were going to the wrong/different place anyway. Thanks, Seth On Thursday, October 6, 2011, Seth Carter <[email protected]> wrote: > That's good to hear. You made me think of something. I wonder if the conflict is because I'm archiving the report.html via the html publisher plugin and I'm archiving the screenshots via the standard "archive artifacts" section. I'll check to see what happens if I archive everything with the native archive artifacts (the the html publisher plugin doesn't give me an option to do more than htmls) > Thanks, > Seth > > On Thursday, October 6, 2011, Paul Hammant <[email protected]> wrote: >> Well it works for me in my Jenkins install at work. I'll agree that it's fiendishly difficult. >> The root cause is JUnit (on which JBehave sits). Nothing is passed into JUnit about its run environment. If it had a setter of some sort, Maven could fill it. Thus any team wanting to know where 'target' is has to jump through a series of difficult hoops to determine that. >> I'll check to see what I'm doing and report back if it is anything special. >> - Paul >> >> On Tue, Oct 4, 2011 at 3:25 PM, Seth Carter <[email protected]> wrote: >>> >>> Hello folks, >>> I have my jbehave tests running on jenkins, I am then publishing the >>> jbehave reports using the jenkins html publisher plugin. As Jenkins >>> can keep historical records of past builds there is an option to "keep >>> historical HTML reports" as well, this allows me to look at last >>> week's build and still be able to view the jbehave report.html that >>> was generated with it. All good - keep in mind these are the native >>> jbehave reports *not* the junit-like reports created via the >>> jbehave-hudson-plugin. >>> I've run into a problem after enabling the screenshot on failure >>> mechanism for my jbehave selenium tests. >>> This is where it gets tricky: >>> When there is a failure the jbehave scenario.html report will contain >>> a link to the specific screenshot "seen" at the time of failure, >>> default is "target/jbehave/screenshots/failed-scenario-{random-number}.png". >>> >>> When running this within a dev environment the link works great. >>> >>> However, when you run this on Jenkins the screenshots end up in: >>> jenkins/job/job_name/build_number/artifact/target/jbehave/screenshots/failed-scenario-{random-number}.png" >>> note the <<artifact/target/jbehave>>, but the associated story report >>> wants to link to: >>> "jenkins/job/job_name/build_number/screenshots/failed-scenario-{random-number}.png" >>> >>> I know I can control the location of the parent directory where all >>> the reports are stored via the >>> StoryReporterBuilder().withRelativeDirectory(), further I can control >>> the directory structure of the screenshots themselves with the third >>> arg in WebDriverScreenshotOnFailure(driverProvider, storyReporter, >>> "{0}/screenshots/failed-scenario-{1}.png")). >>> This also adjusts the link in the final html, which is very cool and I >>> thought I was close to a solution, but on Jenkins I ended up with: >>> jenkins/job/job_name/build_number/artifact/target/jbehave/artifact/target/jbehave/screenshots/failed-scenario-{random-number}.png >>> when I tried to anticipate the directory that Jenkins would be storing >>> the files in. >>> >>> What it seems like I need is the ability to control the links to the >>> screenshots and leave the actual screenshots in their default >>> location. Through filtering in maven and on jenkins I know I can >>> dynamically create the correct link. >>> I know this is a pretty focused issue. Anyone dealt with it? >>> Thanks, >>> Seth >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >>
