Detailed trigger reference

Detailed reference for triggers in Unity Version Control.

読み終わるまでの所要時間 27 分

最終更新 9ヶ月前

The following section provides a detailed reference of all the triggers as well as input and output parameters. Samples are provided for the most common actions.

Add

Heading	Value
Trigger names	`before-add` `after-add`
Description	It executes user scripts when items are added to the source control.
Runs on	Server

Filters

You can use the following filters:

Repository name
Standard input

For example, if

--filter="rep:test,*.cs"

, then the trigger executes only for repository

test

and if at least one of the lines in the standard input is about adding a C# file.

Standard input

A list of files to be added.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger was completed successfully. The items will be added.
Non zero	Failure. `before-add` blocks; `after-add` reports but items already added.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_COMMENT`	The comment given by the user on the add operation.

Checkin

Heading	Value
Trigger names	`before-checkin` `after-checkin`
Description	It executes user scripts when a checkin operation is performed on any client.
Runs on	Server

Filters

You can use the following filters:

Repository name
Standard input

For example, if

--filter="rep:code,CH *search.c*"

, then the trigger executes only for repository

code

and if at least one of the lines in the standard input is about a change (

CH

) in a

*search.c*

file.

Standard input

The standard input receives revision identifiers for all the items involved in the checkin operation, one per line. Each of them is a specially formatted string containing the server's path of the item (independent of any workspace) and the revision specification, so its contents are easily retrieved using the

cm cat

command.

This is the format of the revision specifications, one per line:


status item_path item_type#br:branch;changeset:cset_id@@rep:rep_name@@repserver:server

The meaning of the members in italic is detailed in the following table:

Member	Description
`status`	The status of the item to be checked in: added (AD), changed (CH), moved (MV), deleted (DE)...
`item_path`	The revision's path in server format, which is independent of the client workspace and operating system.
`item_type`	The type of the item: DIR or FILE.
`branch`	The branch of the revision.
`cset_id`	Only available in the `after-checkin` trigger. The unique changeset identifier. Can be used to ease parsing when accessing revisions with `cm cat` or `cm shelveset` in the trigger script, as the string after the first semicolon uniquely identifiesthe revision inside the server.
`rep_name`	The repository name where the revision belongs.
`server`	The repository server and port where the repository belongs.

This example shows standard input supplied to a checkin trigger when making a checkin to the

search.h

changed file:


CH "/" DIR#br:/main/scm001;changeset:61@@rep:doom3src@@repserver:HERMES:8087CH "/search" DIR#br:/main/scm001;changeset:61@@rep:doom3src@@repserver:HERMES:8087CH "/search/search.h" FILE#br:/main/scm001;changeset:61@@rep:doom3src@@repserver:HERMES:8087

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. Items will be checkedin the repository.
Non zero	The trigger reports failure. If the trigger is `before-checkin` the checkin operation is stopped, and the items are not checked in, neither changeset is created. An error message is reported to the client. If the trigger is `after-checkin` , an error message is reported to the client. However, the checkin operation has already been performed.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_COMMENT`	The comment given at checkin time by the user.
`PLASTIC_SHELVE`	This variable indicates whether the checkin is a shelve operation or not.
`PLASTIC_CHANGESET`	Only available in the `after-checkin` trigger. The changeset or changesets that were created as a result of the checkin operation. This variable contains the specifications for the changesets that were created, separated by semi-colons ( `;` ). This is a sample of a variable value with changesets created on two different repositories: `cs:23@@br:/main@@rep:default@@repserver:DARKTOWER:8084; cs:19@@br:/main@@rep:secondrep@@repserver:DARKTOWER:8084` .
`PLASTIC_PENDING_MERGE_LINKS`	Only available in the `before-checkin` trigger. The variable contains information about the merge links included in the checkin operation. The format of the serialized variable is `MergeLinkSpec1;.....;MergeLinkSpecN` . Each `MergeLinkSpec` has the following format: `mergetype:merge_type,source:src_cset_spec[,base:base_cset_spec]` . For example: `mergetype:merge,source:2@@rep:default@@localhost:8084` . The variables are: `mergetype` : can be one of the following constants: `merge` , `cherrypick` , `intervalcherrypick` , `cherrypicksubtractive` , `intervalcherrypicksubtractive` . `source` : the source changeset specification of the mergelink, composed of the changeset number, the repository, and the server. `base` (optional): if mergetype is `intervalcherrypick` or `intervalcherrypicksubtractive` then it's the base changeset specification of the selected interval. Otherwise, the field doesn't appear in the serialized string.
`PLASTIC_MERGE_LINKS`	Same as PLASTIC_PENDING_MERGE_LINKS environment variable but only available in the `after-checkin` trigger.

Comments

The

before-checkin

and

after-checkin

triggers are invoked only once for all the items involved in the checkin operation. The standard input of the trigger will receive a list of the items involved.

This is one of the most complex and useful triggers. Some examples of usages: Checking code before it is checked in on the repository against some validation/formatting tool or sending emails/updating rss feeds when new code is in the repository.

Revision contents can be accessed through the

cm cat

command, specifying the revision specification supplied in the standard input. They can be validated, modified, and then stored back into the server with the

cm shelveset

command. In case a

shelveset

command updates the contents of a revision in the repository, the client performing the checkin operation will automatically update those items, so the contents of the workspace are always correct.

Sample command line creation


cm trigger create checkin-before "checkstyle" "c:\tmp\triggers\checkin-checkstyle.bat"Trigger created on position 1.

Sample trigger script

The following script reads all the standard input and redirects it to the

c:\tmp\triggers\checkinout.txt

file. The trick here is the use of the

find.exe

command to read the standard input in Windows command line

cmd.exe


@@echo offfor /f "tokens=*" %%g in ('find /V ""') do (echo %%g >> c:\tmp\triggers\checkinout.txt)exit 0

Merge

Heading	Value
Trigger names	`before-merge`
Description	This trigger can be used to deny the merge of some branches if certain conditions are not met.
Runs on	Server

Filters

You can use the following filters:

Repository name
Standard input

For example, if

--filter="rep:dev*,*EVIL*"

, then the trigger executes only for repositories whose name starts with

dev

and if at least one line in the standard input is an

evil

merge conflict.

Standard input

The standard input for the

merge

and the

mergeTo

actions is one of the following:

If the merge operation can't be performed, then the standard input is the reason why:

Code	Description
`CONTRIBUTORS_NOT_CONNECTED`	Source and destination are not connected. Returned by the subtractive merge.
`INVALID_CSET_INTERVAL`	The selected changesets interval `(base, source]` is not valid.
`ANCESTOR_NOT_FOUND`	No ancestor found between source and destination.
`CONTRIBUTORS_ALREADY_CONNECTED`	Source is already included on destination. Merge not needed.
`SOURCE_ALREADY_SUBTRACTED`	The source is already subtracted from the destination. Subtractive merge not needed.
`NO_MERGES_DETECTED`	There are no changes between source and destination.

If the merge operation is performed, the standard input is a list of conflicts in the following order:

Directory conflicts
File conflicts
Writable xlinks conflicts

Then add the operations to apply (source changed, deleted, added, and so on). Each conflict and operation must be one per line. Refer to the following examples for each type:

Conflicts

ADD_MOVE [SRC] A "/foo.c" cs:10 - [DST] M "/bar.c" -> "/foo.c" cs:5

CHANGE_DELETE [SRC] C "/foo.c" cs:12 (base cs:7) - [DST] D "/foo.c" cs:7

CYCLE [SRC] M "/server" -> "/bin/server" cs:5 - [DST] M "/bin" -> "/server/bin" cs:5

DELETE_CHANGE [SRC] D "/foo.c" cs:7 - [DST] C "/foo.c" cs:12 (base cs:7)

DELETE_MOVE [SRC] D "/foo.c" cs:10 - [DST] M "/foo.c" -> "/bar.c" cs:10

DELETE_MOVE [SRC] D "/foo.c" cs:10 - [DST] M "/foo.c" -> "/bar.c" cs:10

DIVERGENT_MOVE [SRC] M "/foo.c" -> "/bar.c" cs:5 - [DST] M "/foo.c" -> "/qux.c" cs:5

EVIL_TWIN [SRC] A "/foo.c" cs:10 - [DST] A "/foo.c" cs:5

LOADED_TWICE [SRC] A "/bar.c" cs:10 - [DST] A "/foo.c" cs:5

MOVE_ADD [SRC] M "/bar.c" -> "/foo.c" cs:10 - [DST] A "/foo.c" cs:5

MOVE_DELETE [SRC] M "/foo.c" -> "/bar.c" cs:10 - [DST] R "/foo.c" cs:10

MOVE_EVIL_TWIN [SRC] M "/foo.c" -> "/qux.c" cs:10 - [DST] M "/bar.c" -> "/qux.c" cs:5

XLINK_CONFLICT [SRC] C "/thirdparty" Xlink ->/eb50a746-ab55-4c92-91e4-f98a62cd599f@libs@relativeServer (base Xlink ->/b69de40f-7693-46c6-a9e5-9359a162a39a@libs@relativeServer) - [DST] C "/thirdparty" Xlink ->/ba682b83-4aaf-4169-b1ad-3d8de14b371b@libs@relativeServer (base Xlink ->/b69de40f-7693-46c6-a9e5-9359a162a39a@libs@relativeServer) FILE_CONFLICT [SRC] C "/foo.c" cs:12 (base cs:7) - [DST] C "/foo.c" cs:8 (base cs:7)

Writable Xlinks conflicts that will be expanded with a new merge

XLINK_MERGE [SRC] C "/engine" wXlink ->/235163d5-99c2-4490-988d-204ddd76d963@engine@relativeServer (base wXlink ->/be492aa6-d42d-45be-a7b3-b7d0346fb74f@engine@relativeServer) - [DST] C "/engine" wXlink ->/17cb0014-3351-45f2-9ecb-bc025a43d059@engine@relativeServer (base wXlink ->/be492aa6-d42d-45be-a7b3-b7d0346fb74f@engine@relativeServer)

XLINK_MERGE [SRC] C "/engine" wXlink ->/235163d5-99c2-4490-988d-204ddd76d963@engine@relativeServer (base wXlink ->/be492aa6-d42d-45be-a7b3-b7d0346fb74f@engine@relativeServer)

Operations to apply

```
C "/foo.c" cs:12 (base cs:7)
```

C "/thirdparty" Xlink ->/eb50a746-ab55-4c92-91e4-f98a62cd599f@libs@relativeServer (base Xlink ->/b69de40f-7693-46c6-a9e5-9359a162a39a@libs@relativeServer)

```
A "/foo.c" cs:7
```
```
M "/foo.c" -> "/bar.c" cs:7
```
```
D "/foo.c" cs:7
```
```
FS "/foo.c" 777 (base 444)
```

This is an example for a simple merge:


CHANGE_DELETE [SRC] C "/src/foo.c" cs:12 (base cs:7) - [DST] D "/src/foo.c" cs:7FILE_CONFLICT [SRC] C "/src /bar.c" cs:12 (base cs:7) - [DST] C "/src /bar.c" cs:8 (base cs:7)M "/doc/readme.txt" -> "/readme.txt" cs:7D "/doc" cs:7

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger was completed successfully.
Non zero	The trigger reports failure.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_MERGE_TYPE`	`Merge` / `IntervalSubtractive` / `Subtractive` / `IntervalCherrypick` / `Cherrypick`
`PLASTIC_MERGE_SOURCE`	Specification of the source changeset. For example: `cs:23@br:/main/task@rep:quake@repserver:DARKTOWER:8084` .
`PLASTIC_MERGE_DESTINATION`	Specification of the destination changeset. For example: `cs:19@br:/main@rep:quake@repserver:DARKTOWER:8084` .
`PLASTIC_MERGE_BASE`	Specification of the ancestor changeset. If there are multiple ancestors (recursive merge scenario), they will be separated by semi-colons ( `;` ). For example: `cs:4@br:/main@rep:quake@repserver:DARKTOWER:8084; cs:10@br:/main@rep:quake@repserver:DARKTOWER:8084` .
`PLASTIC_MERGE_SOURCE_LABELS`	The list of labels applied on the source changeset, separated by semi-colons ( `;` ). For example: `6.0.16.1000` .
`PLASTIC_MERGE_HAS_CONFLICTS`	`true` if the merge contains conflicts. Otherwise, `false` .
`PLASTIC_MERGE_HAS_WK_CHANGES`	`true` if the workspace contained changes when the merge started. Otherwise, `false` .
`PLASTIC_MERGE_IS_FORCED`	`true` if the traceability has been ignored to merge and already connected source. Otherwise, `false` .
`PLASTIC_MERGE_STRATEGY`	The strategy used to calculate the common ancestor. Allowed values: `Recursive` or `Manual` .
`PLASTIC_MERGE_IS_MERGE_TO`	`true` if the merge is launched using a merge-to. Otherwise, `false` .

Sample command line creation


cm trigger create before-merge merge_gate "/path/to/script" --server=myserver:8084Trigger created on position 1.

Create branch

Heading	Value
Trigger names	`before-mkbranch` `after-mkbranch`
Description	It executes user scripts when a branch is created.
Runs on	Server

Filters

You can use the following filters:

Repository name
Branch name

For example, if

--filter="rep:default,scm*"

, the trigger executes only for branches whose name starts with

scm

in the repository

default

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The branch will be created.
Non zero	The trigger reports failure. If the trigger is `before-mkbranch` , an error is reported, and the branch is not created. If the trigger is `after-mkbranch` , an error is reported. However, the branch has already been created.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_COMMENT`	The comment given by the user at branch creation.
`PLASTIC_BRANCH_NAME`	The branch that is being created.
`PLASTIC_FULL_BRANCH_NAME`	The full branch name that is being created.
`PLASTIC_REPOSITORY_NAME`	The repository name where the branch is being created.

Create label

Heading	Value
Trigger names	`before-mklabel` `after-mklabel`
Description	It executes user scripts when a label is created.
Runs on	Server

Filters

You can use the following filters:

Repository name
Label name

For example, if

--filter="rep:code,BL*"

, the trigger executes only for labels whose name starts with

BL

in the repository

code

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The label will be created.
Non zero	The trigger reports failure. If the trigger is `before-mklabel` , an error is reported, and the label is not created. If the trigger is `after-mklabel` , an error is reported. However, the label has already been created.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_COMMENT`	The comment given by the user at label creation.
`PLASTIC_LABEL_NAME`	The label that is being created.
`PLASTIC_REPOSITORY_NAME`	The repository name where the label is being created.
`PLASTIC_CHANGESET_NUMBER`	The number of the changeset being labeled.
`PLASTIC_CHANGESET_OWNER`	The name of the owner of the changeset being labeled.

Sample command-line creation


cm trigger create before-mklabel "Validate label" "c:\plastic\triggers\Validate-label.bat" --filter="LB*"Trigger created on position 1.cm trigger list before-mklabel1 Validate label  c:\plastic\triggers\Validate-label.bat dave

Sample trigger script

The following script saves a record of created branches on the c:\plastic\triggers\labels.log.txt file.


@@echo offecho %PLASTIC_REPOSITORY_NAME% %PLASTIC_LABEL_NAME% >> c:\plastic\triggers\labels.log.txtexit 0

Create attribute

Heading	Value
Trigger names	`before-mkatt` `after-mkatt`
Description	Executes user scripts when an attribute is created.
Runs on	Server

Filters

You can use the following filters:

Repository name
Attribute name

For example, if

--filter="rep:code,status"

, the trigger executes only for attribute

status

in the repository

code

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The attribute will be created.
Non zero	The trigger reports failure. If the trigger is `before-mkatt` , an error is reported, and the branch is not created. If the trigger is `after-mkatt` , an error is reported. However, the attribute has already been created.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_COMMENT`	The comment given by the user at attribute creation.
`PLASTIC_ATTRIBUTE_NAME`	The attribute that is being created.
`PLASTIC_REPOSITORY_NAME`	The repository name where the attribute is being created.

Change attribute value

Heading	Value
Trigger names	`before-chattvalue` `after-chattvalue`
Description	It executes user scripts when the value of an attribute applied to a certain object changes.
Runs on	Server

Filters

You can use the following filters:

Repository name
Attribute name
Standard input

For example, if

--filter="STATUS,br*"

, the trigger executes only if the value of the attribute

STATUS

changes and if at least one line in the standard input applies to a branch object.

Standard input

The standard input receives the following detailed information for the object whose attribute value is being changed.

If the trigger is

before-chattvalue

object_spec attribute:"att_name" oldvalue:"old_att_value" newvalue:"new_att_value"

For example:

lb:BL145 attribute:"RELEASED" oldvalue:"FALSE" newvalue:"TRUE"

If the trigger is

after-chattvalue

object_spec attribute:"att_name" value:"att_value"

For example:

br:/main/task985 attribute:"STATUS" value:"OK"

The meaning of the members in italic is detailed in the following table:

Member	Description
`object_spec`	The object which changed attribute value is applied.
`attribute`	The name of the related attribute.
`oldvalue`	The attribute value previously to be changed.
`newvalue`	The attribute value after the change.
`value`	The value of the attribute.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully.
Non zero	The trigger reports failure. If the trigger is `before-chattvalue` , an error messasge is reported, and the attribute value is not changed. If the trigger is `after-chattvalue` , an error message is reported. However, the attribute value has already been changed.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_ATTRIBUTE_NAME`	The attribute which value is being changed.
`PLASTIC_REPOSITORY_NAME`	The repository name where the attribute value is being changed.

Create repository

Heading	Value
Trigger names	`before-mkrep` `after-mkrep`
Description	It executes user scripts when a repository is created.
Runs on	Server

Filters

You can use the following filter:

Repository name

For example, if

--filter="rep:cod*"

, the trigger executes only for repositories whose name starts with

cod

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The repository will be created.
Non zero	The trigger reports failure. If the trigger is `before-mkrep` , an error is reported, and the repository is not created. If the trigger is `after-mkrep` , an error is reported. However, the repository has already been created.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_REPOSITORY_NAME`	The repository that is being created.

Remove repository

Heading	Value
Trigger names	`before-rmrep` `after-rmrep`
Description	It executes user scripts when a repository is removed.
Runs on	Server

Filters

You can use the following filter:

Repository name

For example, if

--filter="rep:test*"

, the trigger executes only for repositories whose name starts with

test

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The repository will be deleted.
Non zero	The trigger reports failure. If the trigger is `before-rmrep` , an error is reported, and the repository is not deleted. If the trigger is `after-rmrep` , an error is reported. However, the repository has already been deleted.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_REPOSITORY_NAME`	The repository that is being deleted.
`PLASTIC_REPOSITORY_ID`	The repository ID that is being deleted.

Create workspace

Heading	Value
Trigger names	`before-mkworkspace` `after-mkworkspace`
Description	It executes user scripts when a workspace is created.
Runs on	Client.

Filters

You can use the following filters:

Repository name
Workspace name

For example, if

--filter="rep:cod*,code"

, the trigger executes only for workspace

code

in all repositories whose name starts with

cod

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The workspace will be created.
Non zero	The trigger reports failure. If the trigger is `before-mkworkspace` , an error is reported, and the workspace is not created. If the trigger is `after-mkworkspace` , an error is reported. However, the workspace has already been created.

Environment variables

In addition to the variables defined in section Common environment variables, the following ones are also available:

Environment variable	Description
`PLASTIC_WORKSPACE_NAME`	The name given to the new workspace.
`PLASTIC_WORKSPACE_PATH`	The path of the workspace on the client machine.

Set selector

Heading	Value
Trigger names	`before-setselector` `after-setselector`
Description	Executes user scripts when a workspace selector is changed.
Runs on	Client.

Filters

You can use the following filters:

Repository name
Standard input

For example, if

--filter="rep:test,/main/Release*"

, the trigger executes only for repository

test

and if at least one line in the standard input matches

/main/Release*

Standard input

The standard input in these triggers receives the selector contents that the client is setting.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The selector will be modified.
Non zero	The trigger reports failure. If the trigger is `before-setselector` , an error is reported, and the selector is not modified. If the trigger is `after-setselector` , an error is reported. However, the operation has already been done.

Environment variables

In addition to the variables defined in section Common environment variables, the following ones are also available:

Environment variable	Description
`PLASTIC_WORKSPACE_NAME`	The name of the workspace which selector is being set.
`PLASTIC_WORKSPACE_PATH`	The client path of the workspace which selector is being set.

Comments

Selectors are modified either with the

setselector

switch

command or with the Switch workspace to branch, Switch workspace to label or Switch workspace to changeset commands, all of them in the command-line interface or the GUI client.

Update

Heading	Value
Trigger names	`before-update` `after-update`
Description	It executes user scripts in the following scenarios: When a workspace is updated. When a `fast-update` operation is executed. When a Gluon workspace is updated (both from the Gluon GUI or by running the cm partial update command).
Runs on	Client.

Filters

You can use the following filters:

Repository name
Path to be updated
Standard input

For example, if

--filter="rep:code,D:*/lib*"

, then the trigger executes only for repository

code

and if at least one of the lines in the standard input is about deleting (

) items in a

lib

path.

Standard input

If the trigger is

before-update

, then no standard input is supplied to this trigger.

If the trigger is

after-update

, then the standard input is

<{0}:{1}>

, where:

```
{0}
```
is the change's type:
- C: Created (new item).
- U: Updated.
- M: Modified on disk (implies not updated nor deleted).
- D: Deleted.
```
{1}
```
is the change's path.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. Update operation will proceed.
Non zero	The trigger reports failure. If the trigger is `before-update` , an error is reported, and the workspace is not updated. If the trigger is `after-update` , an error is reported. However, the workspace has already been updated.

Environment variables

In addition to the variables defined in the Common environment variables section, the following is also available:

Environment variable	Description
`PLASTIC_UPDATE_PATH`	The client path of the workspace that is being updated.
`PLASTIC_INITIAL_CHANGESET`	The ID of your workspace's changeset is (or was) pointing at when the update begins.
`PLASTIC_FINAL_CHANGESET`	The ID of the changeset your workspace is (or will be) pointing at when the update finishes.

Comments

This trigger runs on the client, so the script locations are relative to the client machine filesystems. This is an important difference to note when creating these kinds of triggers.

Create code review

Heading	Value
Trigger names	`before-mkreview` `after-mkreview`
Description	It executes user scripts when a code review is created.
Runs on	Server

Filters

You can use the following filters:

Repository name
Code review title

For example, if

--filter="rep:development,Review*"

, the trigger executes only for code reviews whose title starts with

Review

in the repository

development

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The code review will be created.
Non zero	The trigger reports failure. If the trigger is `before-mkreview` , an error is reported, and the code review is not created. If the trigger is `after-mkreview` , an error is reported. However, the code review has already been created.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_REPOSITORY_NAME`	The repository name where the code review is created.
`PLASTIC_REVIEW_TITLE`	The title given to the code review.
`PLASTIC_REVIEW_STATUS`	`Under review` , `Reviewed` , or `Rework Required` .
`PLASTIC_REVIEW_ASSIGNEE`	The user assigned to the code review, if any. Not set if no user is assigned to the code review
`PLASTIC_REVIEW_TARGET`	The specification of the object for which the code review has been created. Either a changeset or a branch.
`PLASTIC_REVIEW_TARGET_TYPE`	`branch` / `changeset` .
`PLASTIC_REVIEW_ID`	Only available in the `after-mkreview` trigger. The variable contains the identifier of the review that has been created.

Edit code review

Heading	Value
Trigger names	`before-editreview` `after-editreview`
Description	It executes user scripts when a code review is edited. For example, the triggers will be launched when a user changes a review name, the assignee, or the status, or when a review comment is created, edited, or deleted.
Runs on	Server

Filters

You can use the following filters:

Repository name
Code review title

For example, if

--filter="rep:development,Review*"

, the trigger executes only for code reviews whose title starts with

Review

in the repository

development

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. The code review edition is saved to the repository.
Non zero	The trigger reports failure. If the trigger is `before-editreview` , an error is reported, and the code review edition is not saved in the repository. If the trigger is `after-editreview` , an error is reported. However, the code review edition is saved to the repository.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_REPOSITORY_NAME`	The repository name where the code review is edited.
`PLASTIC_REVIEW_TITLE`	The title given to the edited code review.
`PLASTIC_REVIEW_STATUS`	`Under review` , `Reviewed` , or `Rework Required` .
`PLASTIC_REVIEW_ASSIGNEE`	The user assigned to the code review, if any. Not set if no user is assigned to the code review
`PLASTIC_REVIEW_TARGET`	The specification of the object for which the code review has been edited. Either a changeset or a branch.
`PLASTIC_REVIEW_TARGET_TYPE`	`branch` or `changeset` .
`PLASTIC_REVIEW_ID`	The variable contains the identifier of the edited review.
`PLASTIC_REVIEW_COMMENT`	The variable contains the comment that fired the trigger. This variable will be empty if the action that fired the trigger is changing the code review status or the assignee.
`PLASTIC_REVIEW_COMMENT_ACTION`	The variable reflects the action in the comment: `Created` , `Edited` , or `Deleted` . This variable will be empty if the action that fired the trigger is changing the code review status or the assignee.

Client checkout

Heading	Value
Trigger names	`before-clientcheckout` `after-clientcheckout`
Description	It executes user scripts on the client when a checkout operation is executed.
Runs on	Client.

Filters

You can use the following filter:

Repository name
Standard input

For example, if

--filter="rep:code,*.json"

, then the trigger executes only for repository

code

and if at least one of the lines in the standard input is about running a checkout on a

json

file.

Standard input

The standard input in these triggers receives the list of items specified by the user on the checkout operation.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. Checkout operation will proceed.
Non zero	The trigger reports failure. If the trigger is `before-clientcheckout` , an error is reported, and the operation is canceled. If the trigger is `after-clientcheckout` , an error is reported. However, the items have been already checked out.

Environment variables

The variables in these triggers are the same as the ones defined in section Common environment variables.

Comments

This trigger runs on the client, so the script locations are relative to the client machine filesystems. This is an important difference to note when creating these kinds of triggers.

Client checkin

Heading	Value
Trigger names	`before-clientcheckin` `after-clientcheckin`
Description	It executes user scripts on the client when a checkin operation is executed.
Runs on	Client.

Filters

You can use the following filters:

Repository name
Standard input

For example, if

--filter="rep:code,*src*"

, then the trigger executes only for repository

code

and if at least one of the lines in the standard input affects an

*src*

item.

Standard input

The standard input in these triggers receives the list of items specified by the user on the checkin operation.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. Checkin operation will proceed.
Non zero	The trigger reports failure. If the trigger is `before-clientcheckin` , an error is reported, and the checkin operation is aborted. If the trigger is `after-clientcheckin` , an error is reported. The items are already checked in.

Environment variables

In addition to the variables defined in section Common environment variables, the following ones also available:

Environment variable	Description
PLASTIC_COMMENT	The comment specified by the user on the checkin operation.
PLASTIC_CHANGESET	Only available in the `after-clientcheckin` trigger. The changeset or changesets that were created as a result of the checkin operation.
PLASTIC_PENDING_MERGE_LINKS	Only available in the `before-clientcheckin` trigger. The variable contains the following information: The merge links included in the checkin operation. The merge links affecting the repositories under a xlink. The format of the serialized variable is `MergeLinkSpec1;.....;MergeLinkSpecN` . Each `MergeLinkSpec` has the following format: `mergetype:merge_type,source:src_cset_spec[,base:base_cset_spec]` . For example: `mergetype:merge,source:6@rep:xlinkedrepo@repserver:localhost:8084mergetype:merge,source:2@rep:default@localhost:8084` . The variables are: `mergetype` : can be one of the following constants: `merge` , `cherrypick` , `intervalcherrypick` , `cherrypicksubtractive` , `intervalcherrypicksubtractive` . `source` : the source changeset specification of the mergelink, composed of the changeset number, the repository, and the server. `base` (optional): if mergetype is `intervalcherrypick` or `intervalcherrypicksubtractive` then it's the base changeset specification of the selected interval. Otherwise, the field doesn't appear in the serialized string.
PLASTIC_MERGE_LINKS	Same as `PLASTIC_PENDING_MERGE_LINKS` environment variable but only available in the `after-clientcheckin` trigger.

Comments

This trigger runs on the client, so the script locations are relative to the client machine filesystems. This is an important difference to note when creating these kinds of triggers. The

before-clientcheckin

trigger runs once per affected repository under an Xlink and then again for the repository where the checkin occurs. If you don't want this to happen, you can add a filter.

Security

Heading	Value
Trigger names	`after-security`
Description	It executes user scripts when a user performs an operation that has been denied through security permissions.
Runs on	Server

Filters

You can use the following filter:

Repository name

For example, if

--filter="rep:docu"

, the trigger executes only for repository

docu

Standard input

No standard input is supplied to this trigger.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	The trigger completed successfully. Security operation will proceed.
Non zero	The trigger reports failure. If the trigger is `after-security` , an error is reported.

Environment variables

In addition to the variables defined in section Common environment variables, the following ones also available:

Environment variable	Description
`PLASTIC_MESSAGE`	The information about the denied permission.
`PLASTIC_PERMISSIONS`	The denied permissions.
`PLASTIC_REPOSITORY_ID`	The ID of the repository where the operation is executed.
`PLASTIC_REPOSITORY_NAME`	The name of the repository where the operation is executed.
`PLASTIC_OBJECT`	The object with the denied permission.

Replication read

Heading	Value
Trigger names	`before-replicationread` `after-replicationread`
Description	It executes user scripts when a user performs a replication operation that involves reading data. This occurs: In the source side on a push operation. In the source side on a pull operation.
Runs on	Server

Filters

You can use the following filter:

Repository name

For example, if

--filter="rep:code"

, then the trigger executes only for repository

code

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success.
Non zero	Failure. If `before-replicationread` , the operation is aborted. If `after-replicationread` , the item is already replicated.

Environment variables

Environment variable	Description
`PLASTIC_BRANCH`	Complete branch specification being replicated: This is the format of the branch specification: `branch@rep:rep_name@server` . If the trigger is `before-replicationread` , `server` is destination. If the trigger is `after-replicationread` , `server` is the source.

Replication write

Heading	Value
Trigger names	`before-replicationwrite` `after-replicationwrite`
Description	Executes user scripts when a replication operation writes data (destination side of push/pull).
Runs on	Server

Filters

You can use the following filter:

Repository name

For example, if

--filter="rep:code"

, the trigger executes only for repository

code

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success.
Non zero	Failure. If `before-replicationwrite` , the operation is aborted. If `after-replicationwrite` , the item is already replicated.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_BRANCH`	Complete branch specification being replicated: `branch@rep:rep_name@server` . The `server` member will be the destination server.
`PLASTIC_REPLICATION_SOURCE`	Only available in the `before-replicationwrite` trigger. The complete repository specification being replicated. This is the format of the repository specification: `rep:rep_name@@server` . The `server` member will be the source server.
`PLASTIC_REPLICATION_ID`	Only available in the `after-replicationwrite` trigger. The ID of the replication.

Remove branch

Heading	Value
Trigger names	`before-rmbranch` `after-rmbranch`
Description	It executes user scripts when a branch is removed.
Runs on	Server

Filters

You can use the following filters:

Repository name
Branch name

For example, if

--filter="rep:code,dev*"

, the trigger executes only for those branches which name starts with

dev

in the repository

code

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success. The branch will be deleted.
Non zero	Failure. If `before-rmbranch` , it is not deleted. If `after-rmbranch` , it was already deleted.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_BRANCH_NAME`	The name of the branch that is being deleted.
`PLASTIC_FULL_BRANCH_NAME`	The full name of the branch to be deleted, including the parent.
`PLASTIC_REPOSITORY_ID`	The repository ID where the branch is deleted.
`PLASTIC_REPOSITORY_NAME`	The repository name where the branch is deleted.
`PLASTIC_COMMENT`	The comment given by the user at branch deletion.

Rename branch

Heading	Value
Trigger names	`before-mvbranch` `after-mvbranch`
Description	It executes user scripts when a branch is renamed.
Runs on	Server

Filters

You can use the following filters:

Repository name
Branch name

For example, if

--filter="rep:code,dev*"

, the trigger executes only for branches whose name starts with

dev

in the repository

code

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success. The branch will be renamed.
Non zero	Failure. If `before-mvbranch` , it is not renamed. If `after-mvbranch` , it was already renamed.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_BRANCH_NAME`	Current branch name.
`PLASTIC_FULL_BRANCH_NAME`	Current full branch name, including the parent.
`PLASTIC_BRANCH_NEW_NAME`	New branch name.
`PLASTIC_FULL_BRANCH_NEW_NAME`	New full branch name, including the parent.
`PLASTIC_REPOSITORY_ID`	Repository ID where the branch is renamed.
`PLASTIC_REPOSITORY_NAME`	Repository name where the branch is renamed.
`PLASTIC_COMMENT`	Comment given by user when the branch is renamed.

Remove changeset

Heading	Value
Trigger names	`before-rmchangeset` `after-rmchangeset`
Description	It executes user scripts when a changeset is removed.
Runs on	Server

Filters

You can use the following filters:

Repository name
Changeset number

For example, if

--filter="rep:code,3276"

, the trigger executes only for changeset

in the repository

code

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success. The changeset will be deleted.
Non zero	Failure. If `before-rmchangeset` , it is not deleted. If `after-rmchangeset` , it was already deleted.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_CHANGESET_NUMBER`	The changeset being deleted.
`PLASTIC_CHANGESET_OWNER`	Owner of the changeset.
`PLASTIC_BRANCH_NAME`	Branch the changeset belongs to.
`PLASTIC_REPOSITORY_ID`	Repository ID of the changeset being deleted.
`PLASTIC_REPOSITORY_NAME`	Repository name of the changeset being deleted.
`PLASTIC_COMMENT`	Comment given by the user at changeset deletion.

Remove label

Heading	Value
Trigger names	`before-rmlabel` `after-rmlabel`
Description	It executes user scripts when a label is removed.
Runs on	Server

Filters

You can use the following filters:

Repository name
Label name

For example, if

--filter="rep:code*,BL*"

, the trigger executes only for labels whose name starts with

BL

in repositories whose name starts with

code

Standard input

No standard input is supplied to these triggers.

Output result

Result code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success. The label will be deleted.
Non zero	Failure. If `before-rmlabel` , it is not deleted. If `after-rmlabel` , it was already deleted.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_LABEL_NAME`	The label name being deleted.
`PLASTIC_BRANCH_NAME`	The branch name.
`PLASTIC_CHANGESET_NUMBER`	Number of the labeled changeset.
`PLASTIC_CHANGESET_OWNER`	Owner of the labeled changeset.
`PLASTIC_REPOSITORY_ID`	Repository ID where the label is deleted.
`PLASTIC_REPOSITORY_NAME`	Repository name where the label is deleted.
`PLASTIC_COMMENT`	Comment given by user at label deletion.

Remove attribute

Heading	Value
Trigger names	`before-rmattribute` `after-rmattribute`
Description	It executes user scripts when an attribute is removed.
Runs on	Server

Filters

You can use the following filters:

Repository name
Attribute name

For example, if

--filter="rep:code*,resolved"

, the trigger executes only for attribute

resolved

in repositories whose name starts with

code

Standard input

No standard input is supplied to these triggers.

Output result

The resulting code from the trigger script or executable determines the success or failure of the operation:

Output result	Description
`0`	Success. The attribute will be deleted.
Non zero	Failure. If `before-rmattribute` , it is not deleted. If `after-rmattribute` , it was already deleted.

Environment variables

In addition to the variables defined in sections Common environment variables and server.conf variables, these are also available:

Environment variable	Description
`PLASTIC_ATTRIBUTE_NAME`	The attribute name being deleted.
`PLASTIC_REPOSITORY_ID`	Repository ID where the attribute is deleted.
`PLASTIC_REPOSITORY_NAME`	Repository name where the attribute is deleted.
`PLASTIC_COMMENT`	Comment given by user at attribute deletion.

Detailed trigger reference

Add

Heading

Value

Filters

Standard input

Output result

Output result

Description

Environment variables

Environment variable

Description

Checkin

Heading

Value

Filters

Standard input

Member

Description

Output result

Output result

Description

Environment variables

Environment variable

Description

Comments

Sample command line creation

Sample trigger script

Merge

Heading

Value

Filters

Standard input

Code

Description

Conflicts

Writable Xlinks conflicts that will be expanded with a new merge

Operations to apply

Output result

Output result

Description

Environment variables

Environment variable

Description

Sample command line creation

Create branch

Heading

Value

Filters

Standard input

Output result

Output result

Description

Environment variables

Environment variable

Description

Create label

Heading

Value

Filters

Standard input

Output result

Output result

Description

Environment variables

Environment variable

Description

Sample command-line creation

Sample trigger script

Create attribute

Heading

Value

Filters

Standard input

Output result

Output result

Description

Environment variables

Environment variable

Description