Skip to main content
System StatusContact Support Agility Community

Continuum Projects

A Project serves a specific purpose in Continuum. History, metrics, trending details, and logging information are all associated with and can be viewed by Project.

Additionally, Projects can be versioned, and when versioned they additionally group and track all changes managed by any associated Pipelines with that specific version identifier.

Project Types

There are several different types of Projects. Overall, Projects are simply data containers, but we find Projects are typically considered representative of something a little more specific. Project type allows you to designate a more refined purpose for the Project. Valid types are:

  • General. This Project serves a general purpose - pipelines and processes don't have a clear and specific meaning.

  • Source. This Project represents work done specifically around a source code repository. Pipelines typically build and test code in this repository, and are generally defined to support development initiatives.

  • Integration. This Project represents consolidation work, typically fed from Source type Projects. Integration type Projects usually cover building low level code into higher level 'modules', integration testing, and early-stage QA efforts.

There are no specific behaviors associated with the different Project Types - they simply serve as a way to organize and visualize the wide variety of Pipelines and Projects in a typical environment. On the main Projects page, results can be limited to Projects of a designated type.


Just as on a Pipeline Definition, Globals can be defined at the Project level, and are available to all Pipelines running within this Project.

The rules are simple - Globals must be a valid JSON document. For example:

    "best_vampire_slayer": "Buffy"

In any Plugin used in any Pipeline in this Project, it is simple to find out who the best vampire slayer is by using a variable evaluation:

[$ projectglobals['best_vampire_slayer'] $] is the best!

Project globals are best used to define customer specific and mostly static values necessary for automation. They don't change often, and in the case of our example, pretty much never. :-)

Click here to learn more about Referencing Variables.


All Pipeline automation must run within the scope of a Project, and status notification can vary depending on the Project in which a Pipeline is running. Notifications can be managed on the Project management page.

The following Notification events can be enabled:

  • Start - notify when a Pipeline is initiated.
  • Wait - notify when a Pipeline has paused and is waiting for manual user interaction.
  • Success - notify when a Pipeline completes successfully.
  • Failure - notify when a Pipeline ends in failure.

When these events occur, notifications can be sent using the following messaging technologies.

  • Email - sent to a comma-separated list of email addresses.
  • HipChat - messages will be posted to a specified HipChat room. (*)
  • Slack - messages will be posted to a specified Slack #channel or private group. (*)
  • HTTP - to support an array of other notification services, messages can be delivered to any URL via HTTP 'POST'.
    A template for the data to post can also be defined, and [$ variable expressions $] will be replaced with the appropriate value from the Pipeline Workspace document. (**)

(*) HipChat and Slack messaging will make use of the token defined in the global Plugin Configuration file.

(**) In the HTTP body, in addition to [$ variables $], two literal expression are directly replaced - __TITLE - the title of the notification message and __MESSAGE - the notification message text

Context Specific Notifications

In addition to these fixed status notifications available as Project configuration, most of the same types of notifications can be sent directly within a Pipeline, using the appropriate notification plugin. In this case, the developer has complete control over both the notification message and the conditions under which it is sent.

Project Source

If a Project is defined as a Source type, additional tabs are available for configuration.

The Source tab contains details about the source code repository connected to this Project, as well as Directives that are considered when the repository pushed data to Continuum.

Data arriving in Continuum for the very first time is called a Submission. For example, when GitHub is configured to push data to Continuum, the GitHub webhook payload is a Submission, which is then processed as follows:

  • Changes From - identifies which SCM technology and protocol is used to get commit data into Continuum.
  • Use as Group - this rule defines how to identify the Pipeline Group for this Submission.
    • Source Branch - In many cases, the branch in the repository is used as the Pipeline Group, as this is an intuitive way to group all automation by easily seeing which branch the data came from.
    • Lookup in Submission - For more flexibility, this feature can use a [$ variable expression $] evaluated against the entire Submission payload in order to determine the Group. A literal explicit group can also be defined, in which case all submissions from this repository would always be in the same Group.
  • Use Project Version - Similar to Use as Group, this setting allows you to initially define the Project Version to which this Submission will be assigned.
    • Current - the submission will arrive in the most current version of the Project.
    • Source Branch - Often the branch in the repository is named using an external versioning indicator.
    • Lookup in Submission - Again, this feature can use a [$ variable expression $] evaluated against the entire Submission payload in order to determine the Version. A literal explicit group can also be defined, in which case all submissions from this repository would be assigned to an explicit version.

Assigning (or reassigning) Submissions to a specific Project version is a complex and multi-dimensional feature. The simple rules here are not the only way of assigning version, rather the first attempt. Further refinement of version assignment can be applied at a later stage of the downstream workflow for this Submission. For a full explanation of Project Version, click here

Project Actions

Projects can have a number of ad-hoc actions defined. The actions appear in the UI on the detail page for a specific Project.

Project Directives

Project directives define actions to be executed after "source" type projects receive submissions (commits). They are used for things like looking up a workitem in your ALM system or to package a revision into a particular phase. The following types of actions are supported:

  • Continuum CI
  • Initiate Pipeline
  • Run Task
  • Lookup Workitems - VersionOne Lifecycle
  • Lookup Workitems - CollabNet TeamForge
  • Lookup Issues - Atlassian Jira
  • Lookup Workitems - Microsoft VSTS/TFS
  • Package into Phase
  • Redirect to Project
  • Assign to Pipeline
  • Assign to Version
  • Plugin Function
  • Ignore Submissions
  • Stop Processing


Data Flow Mapping

The Data Flow tab lets you configure Pipelines to pass data on to other downstream Pipelines of the same project or to Pipelines on other projects. 

To set up Data Flow mappings:

  1. Open a project, select the Data Flow tab.
  2. Click Add New


  • From Project: Select the source Pipeline definition and Group whose data you want to be passed to the other Pipelines.
  • To Project: Select the target Project, Pipeline and Group to which you want the source Pipeline's data passed on.
  1. Click Add Mapping and Save.