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 >> >> > >
