Hudson task configuration instructions

Hudson task configuration instructions

 

 

 

 

Discard Old builds: Hudson retains the previous build by default. If this option is selected, you can set the validity period of the build record;

(Help: here you control the validity period of the building record storage on the disk where Hudson is located;

Hudson provides two standards for this purpose: 1. time-driven-In Hudson, you can determine if a certain time limit is reached to delete a record (for example, 7 days ago); 2. number-driven-In Hudson, you can ensure that it has n builds. If a new build starts, the earliest one (record) will be deleted. Hudson can also define your individual build as 'Keep this record forever 'to prevent important builds from being automatically discarded .)

ØThis build is parameterized: If this option is selected, Hudson will allow you to provide a set of any key-Value Pair parameters that will be passed to the build process. Configuration parameters are usually some environment variables in the build runtime environment.

(Help: When you use Hudson's various automation, you sometimes need to provide a set of user input during the build process, and use "parameterize" to facilitate the build. For example, you may set up an on-demand test where you can submit a compressed binary file for testing. The parameters in this section can be configured as needed. Parameters are separated by names, so you can have multiple parameters as long as they have different names. The parameters in this section can be configured as needed. Parameters are separated by names, so you can have multiple parameters as long as they have different names .)

 

ØDisable build(No new builds will be executed until the project is re-enabled.): If this option is selected, the build will not be executed until the option is disabled. (Help: Sometimes you want to pause a project in a build. For example, you may be preparing a large migration, and you know that the new version will fail. Or you want to build it every hour, but you find that the CVS server will be down within the next 24 hours. When this option is set, there will be no new build for this project. In this way, you can disable the build process without changing external dependencies or submitting Error notifications .)

ØExecute concurrent builds if necessary(Beta ):

 

Advanced project options

ØQuiet Period: If this option is set, the number of seconds to wait for the building in a plan to be set in the option before it starts.

ØRetry count: If the version library check-out Code fails, Hudson will retry Based on the specified number of times before giving up;

ØBlock build when upstream project is building

ØBlock build when downstream project is building

ØUse custom Workspace: By default, Hudson creates a workspace under $ {home}/. Hudson/jobs/[project name. This option allows you to replace it with the specified address ).

ØClean workspace before build:Clean up the workspace before building

Source code management

 

Repository URL: code repository URL

Local Module Directory (optional): the directory that is checked out to the Workspace

Build triggers

Build after other projects are built: This option supports an assembly line-job dependency: where one job depends on the output of another job-or in the following situations: you just want to simply build some related projects into a group to build them together. When you select it, you will get a field. After you enter the name of another project [separated by commas (,) for multiple project names, this build should be ready to run.

Build periodically: (regular build) This option (also using a scheduled job expression) only notifies Hudson to build the project at a specified frequency, regardless of whether the SCM has changed. My job is in the target testing environment where it is regularly revised in some way, while SCM is static. It may be helpful if you want to run some test cases in this job.

Poll SCM: this is a common option in CI systems. When this option is selected, you can specify a regular job expression to define how often Hudson checks for changes to your source code repository. If changes are detected, perform a build. For example, if you enter, *** in the expression, Hudson will check your source code repository changes every 15 minutes.

Build when Maven dependencies have been updated by Maven 3 Integration

Build when Maven snapshot dependencies have been updated externally

 

Added an instruction to execute the build script;

 

• Ant version: Specifies an ant instance for construction.

• Targets: A series of targets in the specified ant script file will be called. Leave it blank. In this case, the default task of the script will be executed.

• Build File: the path where the ant script is stored after execution. It is in the same directory as the current workspace.

• Properties: these additional defined system properties can be passed here to the ant script. My script here contains some attributes for Identity Authentication through my subversion repository, because my program includes a step to put some changes back to the repository. In addition, I have defined other attributes to configure parameters for my unit test.

• Java options: the Java command line options can be passed here. With this configuration, you can use ant-Debug to generate a specific diagnosis log while debugging the problems in the script. Other common options include specifying the minimum and maximum java stack sizes (-XMS and-xmx ), this reminds you to enable a new JVM instance in Hudson to run your build script.

 

 

Publish checkstyle analysis results: release analysis source code report

Publish findbugs analysis results: Build scripts to execute findbugs static code, which is used to analyze the source code of the job and generate a survey report. This option indicates that the Hudson findbugs plug-in is installed. It instructs Hudson to retrieve findbugs XML result reports, summarize them to the historical trend of the current job, and expose them to the home page of the current job. The advanced options of the findbugs plug-in allow you to determine the asserted category when findbugs reports, and how they affect final determination when Hudson gets information about the status of the current job.

Publish PMD analysis results:

(Install the PMD plug-in. This plug-in mainly collects the analysis results of the PMD (program code Check Tool) in the project module and displays the detected warnings in a view)

Scan workspace for open tasks:

Scan for Compiler Warnings: View compiler warning information

Publish combined analysis results

Build other projects: This option is mainly used to implement a logical build and test process. It is divided into two or more physical jobs and will be executed in order. When this option is selected, you will get a field where you can enter the names of other jobs you want to execute after the current job [multiple jobs can be separated by commas]

Aggregate downstream test results: in some cases, a group of unit tests in a job takes much longer time than actually building it. In these cases, you can divide the build and test into different jobs so that the build can be completed relatively quickly. Once one or more test jobs related to this project are executed, the build is successful. When this option is selected, Hudson will count the test results of the created job and trace them back to their details as the main basis for successful or failed construction.

Publish javadoc: applies to any javadoc content generated during the build process. If the build script can generate javadoc, this option instructs Hudson to publish the content, and immediately publish it on the home page of the current job. The content of each successfully constructed document can be retained, but only the latest content is retained by default.

Transferred from

Http://eileenlml.iteye.com/blog/1536226

Record fingerprints of files to track usage: using a mask similar to ant can instruct Hudson to generate build fingerprint codes to make it easier to locate their locations, in addition, determine whether the components in the system are still in use.

Publish JUnit test result report: If the build script executes the JUnit test, this option instructs Hudson to process the XML test document and generate a sustainable report for each continuous build, summarizes the processing results based on ongoing tests.

(Instruct Hudson to obtain a JUnit XML result file on the defined path and summarize them to the historical trend report .)

Archive the artifacts: When you select this option, you can specify the file and directory mask (Ant-style mask, which can be included and excluded ), components that match the mask will be added to the Hudson component repository during building, which will be identified by the job (name) and build number. All previously built components can be selectively discarded to save disk space on your Hudson server.

Publish cobertura coverage report: the build script uses cobertura as the container for generating class files based on code override commands. When the JUnit test is run, cobertura monitors the coverage of the code and generates a coverage report after the test is completed. This option indicates that Hudson cobertura has been installed. It instructs Hudson to retrieve identified cobertura XML coverage reports, summarize them to the historical trends of the current job, and expose them to the home page of the current job. The "coverage metric targets" option indicates that when Hudson gets the status of the current job, you can specify the coverage level in the code override map to influence the final determination.

Record fingerprints of Maven 3 artifacts

Archive Maven 3 artifacts

Publish testing tools result report

Git publisher

E-mail Notification: defines a Mail List (separated by spaces) to send a notification when the build fails. When a job is always unstable or terminated, you can choose "Send email for every unstable build" to prevent Hudson from sending an email notification with the specified conditions.

Using Y that Maven dependencies have been updated by Maven 3 Integration

Perform subversion tagging on successful build

Hudson task configuration instructions