Configure Job Protection Settings

To restrict access, the project owner can mark a job as private. Users that don't have access can see the build job in the Jobs Overview page, but they can't see the Job Details page or view the build's details; nor can they see or edit the job configuration, or delete/enable/disable the build job. In addition, the project owner can use a glob pattern that is defined in a rule to protect any job whose name matches the specified pattern.

Note:

Before you apply any protections to a job, you should consider the following:

A protection rule defined with a glob pattern will not overrule a job protection defined by using a name (no glob pattern or rule).
A protection that is applied to a single job will override a protection applied by using a rule (defined by a glob pattern).
When two rules are combined, the protection is determined by the most restrictive rule. You need to look at the events in the Activities feed and examine the notifications, which provide the information explaining the restrictions when one rule overrides another.
A job will not be created if the user that is creating the job wouldn't be able to access their own job. The same principle is true for renaming jobs.

In the left navigator, click Project Administration .
Select the Builds tile.
Select the Job Protection tab.

The Job Protection page is displayed.

Description of the illustration job-protection-page-initial.png
In the Find rules by panel, located above the jobs/rules list, select one of these radio buttons:
- Select Job name to choose a job from the list.
  If your project has many jobs, you may have difficulty finding the specific job you want to protect. Use the Filter job bar to quickly locate the job to which you want to add the restricted settings.
  
  If a job in the list of jobs to the left has a lock icon next to it, it has already been protected. A protected job's restrictions can still be modified, removed, or the list of authorized users and groups can still be changed.
  
  The Job Protection dialog box is displayed.
  
  Description of the illustration job-protection-open.png
  When a job is not directly protected but is protected by a rule instead, an informational message like the following one, will show the rules, <ExampleRegex05> in this case, that protect the specific job:
```
This job is proctected by the following glob pattern rules matching this job name: <ExampleRegex05>
```
- Select Glob pattern to specify a string that is matched against the job name.
  This is what you'd see if no rules have been defined yet.
  
  Description of the illustration job-protection-page-glob-pattern-selected.png
  
  The glob syntax can be used to specify pattern-matching behavior. These wildcard characters can be used in glob patterns: *, **, ?, [], {}, and \.
  
  Either select an existing protection rule from the list or click + Rule to display the New Protection Rule dialog and create a new one.
  
  The Protection Rule dialog box is displayed.
  
  Description of the illustration protection-rule-dialog-populated.png
  Here we've entered a name (Test Rule) and a glob pattern (test*) and we're about to press Create to create a new job protection rule.
Select the PRIVATE check box.
This is what you see after selecting the Private option for a job.

Description of the illustration job-protection-private.png

With just this option selected, only authorized users and groups will be able to view the Job Details page, edit the job, or manually run it. If the job is triggered in a pipeline by an unauthorized user or group, or if it is triggered by SCM or a timer, it will not be initiated.

This is what you see after selecting the Private option for a protection rule.

Description of the illustration job-protection-rule-private.png
Click in the Authorized Users/Groups field to display a dialog that lists the project's Groups and Users you can select from.

Under Users, you can see a flattened list of all users that are members of the group(s) as well as ones that were added individually. For example, the dev-group members (Clara Coder, Don Developer, and Tina Testsuite) appear in the Users list, along with Alex Admin, who was added individually. From the list, select one or more groups and/or users. Don't forget to add yourself.

Description of the illustration authorized-groups-and-users.png

This is what you would see for the myProtectedJob job after selecting Alex Admin as an authorized user.

Description of the illustration job-protection-private-authorized-user.png

This is what you'd see for the Test Rule protection rule after selecting Alex Admin as an authorized user.

Description of the illustration job-protection-rule-authorized-user.png
Select the checkboxes to allow project members to manually start private jobs and/or allow commits and triggers to automatically start private jobs:
- Select the Allow any member of the project to manually start this private job checkbox to allow any project member, not just authorized users, to manually start the job.
  
  This what you'd see after selecting the Allow any member of the project to manually start this private job check box for the myProtectedJob job.
  
  Description of the illustration job-protection-private-both-checkboxes-selected.png
  
  Notice that when you select the first checkbox, VB Studio automatically selects the second checkbox, which allows commits and triggers to start the private job, and grays it out. With this setting, only authorized users and groups can view the Job Details page or edit the job, but any project member can start and run the job. In addition, SCM commits or triggers will also automatically start and run the job.
  
  This what you'd see after selecting the Allow any member of the project to manually start this private job check box for the Test Rule protection rule.
  
  Description of the illustration job-protection-page-both-check-boxes.png
- Select just the Allow commits and triggers to start this private job checkbox if you want SCM commits and triggers to be able to automatically run this job.
  
  Description of the illustration job-protection-private-allow-commits-and-triggers.png
  
  With just this checkbox selected, periodic triggers will run any job or pipeline, including private jobs set to allow commits and triggers to start the private job. However, if a pipeline includes a private job with this option selected and a non-authorized user attempts to run the pipeline manually, the private job won't run but periodic triggers and SCM commits will.
  
  Leave the checkbox unselected if you don't want the job to be started when it is triggered by an SCM commit or timer.
  
  Note:
  
  Best Practice:
  
  If you use the checkbox to enable the protected build to be triggered by an SCM commit, you need to protect the branch that the build job is tied to. If you don't do this, anyone can trigger the protected build by making a commit to trigger it.
  
  This is what you would see if you selected the Allow commits and triggers to start any job matching this glob pattern for the Test Rule.
  
  Description of the illustration job-protection-page-allow-commits-and-triggers.png
Click Save.

The activity stream displays all changes to a job's protection status, like changing the job protection from public to private, or private to public, or changing a private job to allow commits and triggers.

You can see if a job is private from several places in the VB Studio user interface. A private job is indicated by a Lock icon:

In the jobs list found on the Job Protection tab on the Project Administration page's Builds tile, to the right of each protected job's name.
In the Private column on the Builds page's Jobs tab.
In the jobs shown in the Pipelines tab on the Builds page.

An unauthorized user can't run a private build job manually, through a pipeline, or by using an SCM/periodic trigger.