Skip to content

Latest commit

 

History

History
48 lines (37 loc) · 3.04 KB

WRITING-NETCI.md

File metadata and controls

48 lines (37 loc) · 3.04 KB

Writing CI definitions.

todo add basic info here on the way that the dsl works

Many projects have simple definitions, or at least start out with simple definitions. Clone a repo, run the build and test, gather XUnit.NET test outputs. While you can write your script from scratch, a lot of utility functionality is available while generating jobs. This utility functionality is located in (jobs/generation/Utilities.groovy). Below are annotated examples of CI definitions. The CI definition language is very powerful and can generate a wide variety of jobs very quickly.

Examples in the wild:

How do I...?

This section contains answers to frequently asked questions about how to do certain things.

  • Archive artifacts - After creating a job, add a call to Utilities.addArchival. addArchival takes two parameters: job to add archival for, and the ant style glob pattern indicating what should be archived. When archiving data, archive only what you need and avoid archiving excessive amounts. A third optional parameters is an exclusion list. Example:

    // Below we archive everything under bin except anything under obj, and everything under logs.
Utilities.addArchival(myNewJob, `"bin/**,logs/**"1, `"bin/obj/**"`)

  • Add xunit result gathering - A lot of projects use xunit to report test results. Jenkins can report and track these results in the UI. To enable this, you need to tell Jenkins where the xunit result files are. Make sure your job outputs the results with predictable names so that they can be identified with glob syntax (e.g. bin/testResults/*.xml or bin/**/testResults.xml). Use Utilities.addXUnitDotNETResults to add archiving of results:

// Below we pull in test results in all files named TestRun*.xml anywhere under the tree rooted at bin.
Utilities.addXUnitDotNETResults(newJob, 'bin/**/TestRun*.xml')
  • Add a private github PR trigger - Sometimes you need to restrict a PR trigger to a specific set of users. The new TriggerBuilder class can achieve this for you.

For reference, this is useing the new TriggerBuilder class. See Trigger Builder.

// Create a new TriggerBuilder
TriggerBuilder prTrigger = TriggerBuilder.triggerOnPullRequest()
// Permit anyone in the Microsoft org (can be called multiple times)
prTigger.permitOrg('Microsoft')
// Permit a specific user (can be called multiple times)
prTrigger.permitUser('mmitche')
prTrigger.permitUser('smile21prc')
// Maybe we only want a specific phrase (this is regex)
prTrigger.setCustomTriggerPhrase("(?i).*test\\W+test my sweet new job.*")
// And, enable for the branch we are targeting in this CI definition file
prTrigger.triggerForBranch(GithubBranch)
// Set up what shows up in Github:
prTrigger.setGithubContext('My New Job')
prTrigger.emitTrigger(myNewJob)