Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Automatically trigger a build whenever a check-in occurs in a tracked VCS.
  • Referencing components of the VCS in build actions.
  • Monitor and record changes in the repository. These include changesets that triggered a build or changesets that have been added since the previous build was run.
  • Show changesets that were committed by the current user. For a user to correctly view their own changes, they will first need to configure their Repository User Mappings.
  • Link a repository to an Issue Connector. This allows you to automatically link repository check-in comments to an issue in your issue tracking system.

Repository Caches

Unlike some other continuous integration servers like FinalBuilder Server, Continua CI manages the retrieval of your source code. When you create a repository in Continua CI, it points the Continua server to your VCS. The polling frequency of each repository can be set to specify how often the Continua server polls the VCS for changes.

Continua maintains several caches of your source code: one on the Continua server and one on each agent that has previously used that repository. When Continua detects a new commit/check-in/changeset in your repository, it updates the server cache, then each agent that has that repository cached updates its cache from the server. This means that when it's time to run a build the source is most likely already on the Agent. 

The first time that an agent uses a repository its cache needs to be created. Depending on the size of your source, this can mean that the initial stage on that agent can take significantly longer than usual. After the cache is created though, keeping it updated is usually very quick (unless you add large binaries etc).