...
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
{anchor:myAnchor}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.
...