Options
Todo
Rules
There are three types of rules in Continua:
Workspace Rules
Workspace rules allow you to control which files in the work space are synced or not synced between the server and the agent. Workspace rules are not used to move files from external locations into the workspace. For getting files into your workspace, use the Copy Action or Repository Rules. Rules are split into include rules and exclude rules:
Include Rules
Include rules follow the simple syntax: <server_pattern> <operator> <agent_pattern>
The operator specifies the direction of the rule and the action to take when moving the file. The table below lists the operators and their behavior:
| Operator | Direction | Behavior |
|---|---|---|
| > | Server to Agent | Match files on the server using the server_pattern and copy them to the destination specified by the agent_pattern. Preserves paths. |
| -> | Server to Agent | Match files on the server using the server_pattern and copy them to the destination specified by the agent_pattern. Doesn't preserve paths. |
| >> | Server to Agent | Match files on the server using the server_pattern and copy them to the destination specified by the agent_pattern. Empties the destination directory before copying the files. |
| < | Agent to Server | Match files on the agent using the agent_pattern and copy them to the destination specified by the server_pattern. Preserves paths. |
| <- | Agent to Server | Match files on the agent using the agent_pattern and copy them to the destination specified by the server_pattern. Doesn't preserve paths. |
| << | Agent to Server | Match files on the agent using the agent_pattern and copy them to the destination specified by the server_pattern. Empties the destination directory before copying the files. |
The server pattern is always to the left of the operator and the agent pattern is always to the right. When using a Server to Agent operator, the server pattern is the source and the agent pattern is the destination. When using an Agent to Server pattern, the server pattern is the destination and the agent pattern is the source. The pattern that's the destination pattern isn't really a pattern, it's purely a directory in which the matched files from the source pattern are put. The pattern that is the source is what is used to find files in the source location, therefore this pattern must always contain a wildcard. The wild cards used are:
| Wildcard | Behavior |
|---|---|
| ** | Matches anything in any directory |
| * | Matches any files in the directory |
| ? | Matches a single character in a filename/directory |
Scenarios and examples of workspace include rules can be found on the Workspace Rules page.
Exclude Rules
An exclude rule is defined by putting a dash ( - ) at the start of the rule. An exclude rule only needs to specify an operator (for direction) and a source pattern. The operator type doesn't matter, as long as you get the direction of it correct. The destination pattern is irrelevant because the exclude source pattern is applied to all files captured by all include patterns.
Scenarios and examples of workspace include rules can be found on the Workspace Rules page.
Repository Rules
A repository rule is used to get files out of the repositories attached to the Configuration and into the workspace. Repository rules look and function similar to workspace rules but have a few extra constraints.
- Repository rules can only be Server to Agent rules. If you need files in the repository synced back to the server then you would use an Agent to Server workspace rule.
- Repository rules will always preserve paths regardless of the operator you use.
- A repository rule's source pattern must always contain a reference to the repository using Query Syntax. Eg. $Source.MyRepo$ > MyRepo
- Unlike workspace rules, an exclude repository rule must always contain a destination directory.
In addition to explicitly specifying a repository using query syntax, eg. $Source.MyRepo$, you can also specify all repositories attached a Configuration by using the syntax $Source$. Take note of where the repositoies will be placed when using this syntax though, if your rule is $Source$ > Repos, then your repository will be placed in Repos\<repository_name>. As you can see, the destination directory you specify in the rule is created, then another directory with the name of your repository is created and the repositories' files placed in that.
You can also take advantage of wildcards when specifying a repository rule. For example, your rule can look something like this: $Source.MyRepo$\WebProject\** > MyRepoWeb. Here, we've specified the repository MyRepo but in addition also specified a directory within the repository. This rule will only copy the contents of that directory rather than the entire repository into destination directory MyRepoWeb.
Important: When creating your workflow and adding actions, you may want to use the $Source.MyRepo$ syntax to reference something in your repository. That syntax will only work in your action if you have specified a simple repository rule, eg. $Source$ > Source or $Source.MyRepo$ > MyRepo. It will not work when you use a pattern to specify parts of a repository, eg. $Source.MyRepo$\WebProject\** > MyRepoWeb. If you want to use files in MyRepoWeb then reference it as if you were referencing anything else in the workspace, eg. $Workspace$/MyRepoWeb/file.xml.
Artifact Rules
Artifacts
Todo
Agent Requirements
Todo