Versions Compared

Key

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

To create a new release, navigate to the Search Releases screen using the Releases menu.  

Click on the Image Modified button to create a release.  To edit a release, click on the release name link in the Name column.

Field

Description

Name

The name of the release.
Status

The current status of the release (read-only). 

  • Not Started - the release is not yet started, and is not eligible to process snapshot
  • Started - the release is eligible to process snapshots
  • Suspended - the release has been paused, and is not currently eligible to process snapshots
  • Completed - the release has ended, and will never process snapshots again (cannot be resumed).

Description

An optional description for the release.

Start Date

The date and time in which the release was started (read-only).
End DateThe date and time in which the release was ended/completed (read-only).
PipelineThe pipeline which is used to process snapshots for the release.
Snapshot Schedule

Cron expression to initiate the creation of a snapshot using new project versions for all release projects. Project-level Scheduled Build triggers are created, which can be viewed from project screen as well. More than one cron expression can be provided using ; separator. This would allow for more complex schedules. But all projects in the release will use the same schedule.

For example,

  • 0 0/10 * 1/1 * ? *  - create snapshot if changed every 10 minutes
  • 0 15 10 ? * *  - create snapshot if changed at 10:15 AM every day

If a project added to the release does not have Build Environment selected, then it will not be part of snapshot creation. The latest project version will be used for the project.

When Release is Ended, all Scheduled Build triggers for each project which are associated with the release will be deleted.

Info
titleRelease scheduled build processing
  • All projects in release with Build Environment set will be setup for snapshot schedule. This will initiate a build for each release project by creating a snapshot for the release containing all new project versions. You can view (but not edit) associated Scheduled Build triggers on project screen (CI tab) as well. They are automatically managed when the Snapshot Schedule is configured for a Release.
  • A single release snapshot is created even when more than one project is found to have changed in SCM.
  • Projects with SCM set to None
    • Change detection is not possible
    • If there is a newer version for the project than what is in latest snapshot, new snapshot will contain newer version.
    • Build is never invoked automatically in this case as SCM is None.
  • Projects with SCM other than None
    • Change detection will be performed.
    • If changes are detected in SCM, new build will be initiated for those projects.
    • If no changes are found in SCM, then latest version for project/stream/package will be used.
  • If there are no changes found in any projects or no newer project versions, then snapshot is not created.
  • Project can be defined to be part of multiple releases with same stream. In such situations, if projects is built once, even without release selection, that latest project version will be included in all releases that contain that project with specific stream, when individual snapshot schedule trigger fires for those releases.


...

Tip
titleExample

A "Release Manager" role could have Group1 as a member for Release1 and Group2 as a member for Release2.


Image RemovedImage Added

The list of pipeline roles from the associated pipeline are displayed along the left-hand side.  To view the members, select a pipeline role.  Those members are displayed on the right. 

...

The Pipeline Properties tab lists the properties, according to the metadata defined on the associated pipeline.  Enter or select values to decorate the release.

Image RemovedImage Added 

The properties are available as variables in the pipeline Groovy scripts, to deployment workflows, and their plugins.  These properties are very powerful, as they enable customization of pipelines.

...

The pipeline associated to the release optionally defines a set of pipeline roles, and assigns them default permissions related to releases.  The Security tab allows for viewing of those roles, the default granted permissions, and allows override for that release if necessary.

Image RemovedImage Added


By default, the permissions are defined and shared (by all releases) on the pipeline.  As shown above, you can see the permissions which are inherited by the release from the associated pipeline.  To override, click on the  button.  To fallback to the default permissions defined by the pipeline, click on the  button.  When overriding the security, the page flips from read-only to editable check-boxes.


Image RemovedImage Added


Permission

Description

Read

Grants the pipeline role permission to view release.
Create/Update

Grants the pipeline role permission to create and update the release. Applies to header level fields like name and description only.

Prior to 4.6.0.4, this permission was required for other Configure permissions defined below.

Create SnapshotGrants the pipeline role permission to create snapshots for the release.  Includes builds associated to release, direct creation of snapshot, and promotion of existing project version to the release.
Configure Project ListGrants the pipeline role permission to add/remove projects and packages to/from the release.
Configure PipelineGrants the pipeline role permission to associate the release to another pipeline.
Manage LifecycleGrants the pipeline role permission to Start, End, and Pause the release.
Grant PermissionsGrants the pipeline role permission to configure the Security tab of the release.

...