...
Scenarios and examples of workspace include exclude rules can be found on the Workspace Rules page.
...
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
Scenarios and examples of repository rules can be found on the Repository Rules page.
I'm using a Server to Agent rule to put the repositories content's in the agent's workspace but the repositories content's aren't in the server workspace, how does that work?
When a build starts and the workspace is initially created on the server, the contents of that build's workspace contain no trace of any repositories. Instead, the server will process the repository rules and determine which repositories need to be synced to the agent. The agent will then take note of those repositories and update its repository cache. The agent then runs the repository rules against the repository in its repository cache. This eliminates the need for the server to deal with any copying of repositories. It also has the advantage of making subsequent builds a lot quicker. Instead of having to copy the repository from the server to the agent each build, the agent simply does a local copy from its repository cache into the workspace directory.
Artifacts
An artifact rule is purely a file or a pattern with a type tagged on the end of it. There's no concept of a source, destination or even a direction. It uses the same wildcards as workspace/repository rules but that's about all they have in common. Artifact rules are just a way of registering files as artifacts. When a file is registered as an artifact, it will be listed on the Artifacts page with details of the file and the ability to download and possibly view that artifact. All view able artifacts can be view in their raw format which leaves the rendering of that artifact up to the browser you're using. Alternatively, you can specify a view type for that artifact which will use Continua's custom renderer to display the file. The list of view type are: variable, image, and nunit. You need not worry about the variable type as that's for viewing the variable output files that are generated every build and automatically registered as artifacts. If you're registering an image as an artifact, use the image type when specifying an artifact rule. For nunit xml output files, specify nunit as the view type. If none of your artifacts match a view type then you don't need to specify one, just specify the file/pattern.
When specifying a view type, put it at the start of the rule followed by a vertical bar ("|") character then the pattern. Eg. nunit | **test*.xml. This will match all files in the workspace that contain the word "test" and have a xml file extension.
Important: Artifact registration only happens on the server side, therefore, the patterns are run against the workspace on the server. When writing your workspace rules, make sure you sync back the files you want registered as artifacts. For subsequent stages, make sure you don't delete artifacts registered in previous stages from the workspace on the server. One possible way of doing this without knowing is to create a rule that syncs files from the agent to the server and specifying that the destination directory (which would be on the server) be empty. In this case you would empty the directory with the artifact in it.
Scenarios and examples of registering can be found on the Artifact Rules page.Todo
Agent Requirements
Todo