We're doing
root-project-dir/jbehave-webdriver/target/jbehave/view/**,**/target/jbehave/screenshots/**, **/navigator.html, **/sauce_connect.log "in files to archive" in Jenkins. but I see that you've progressed anyway :) On Thu, Oct 6, 2011 at 2:40 PM, 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 > >> > >> > > > > >
