-
Notifications
You must be signed in to change notification settings - Fork 0
How to and Best Practices
This page is a collection of helpful information for using SASUnit more efficently.
Inspired by a user submit in the forum, I decided to publish the answers here, because they are too long to fit in a post. And they are worthy for other users too.
So you see if you post questions you can contribute to the contents of this wiki.
- Usage of new setup scripts: Explaining SASUnit setup script
- Best practice configuring SASUnit
- How to create your own SASUnit style
- author
- brief
- copyright
- date
- defgroup
- details
- file
- ingroup
- link
- param
- return
- retval
- sa
- todo
- test
- bug
- version
- remark
- deprecated
SASUnit Plugin moves a part of SASUnit configuration (the path to SASUnit installation) into jenkins. Now you can influence SASUnit from within jenkins. The value of the jenkins variable is pass on to SASUnit as an enviroment variable by the *.ci.*-scripts. Now you can use one(!) jenkins job on nodes with different operating system because paths can be specified on master and node. If no definition on a node is present the definition of the master is used. Using the plugIn you can manage multiple SASUnit version under jenkins.
Currently SASUnit Jenkins PlugIn is not kept up to date.
DoxyGen is no longer used but the dialog still has the according checkbox.
HMS has switched to GitHub so the PlugIn can no longer be used.
Currently there are no plans to update SASUnit Jenkins PlugIn.
Displaying SASUnit logfiles in jenkins is done by using post build step "Archive the Artifacts". Just tell that you search the whole workspace for log files. Ant syntax to do that is "**/*.log".
In the screenshots you will see that there are to serch request. One for *run_all.log and one for *junit.xml
This is the result in Jenkins:
Using the jenkins feature of showing the number of passed asserts you can get an overview of the test outcome. And the build status ist dertermined by your SASUnit results. Build status is automatically determined by the created JUnit-XML. If there are no failed asserts the build is stable. If there are failed asserts the build is unstable.
To use this feature you need to do two things:
- Configure SASUnit to create an JUnit-XML file
- Tell Jenkins to evaluate this JUnit-XML file
SASUnit will create a JUnit-XML file if you soecify o_junit in the macro call of reportSASUnit:
%reportsasunit(
i_language =%upcase(%sysget(SASUNIT_LANGUAGE))
,o_html =1
,o_junit =1
);
SASUnit then creates a JUnit-XML-file alongside the HTML documentation (under ..../rep).
By using the jenkins post-build step "Publish JUnit test result report" you can display the result of your SASUnit build.
The only thing left to do is telling Jenkins where to search for this file:
**/*junit.xml tells jenkins to search all folder in the workspace for "*junit.xml"
This is the result in Jenkins:
Displaying SASUnit documentation in jenkins is easy. You can use the jenkins post build step "Publish HTML Reports" to do that.
In our SASUnit tests there are to different calls to SASUnit, that create two different HTNL Reports
This is the result in Jenkins: