Skip to content

Synchronize GitLab milestones and iterations in the Execution workspace of Squash TM

What it does

If an Xsquash4GitLab sprint synchronization is configured, GitLab sprints are automatically synced in the Execution workspace in Squash TM and updated on a regular basis. The synchronization path (folders and sprint group) as well as all the sprints are created during the first update.

The synchronization is only one way, from GitLab to Squash.

Info

Only the creation and content (tickets) of sprints are concerned by the synchronization. For everything else, including tickets validation, the management of synchronized sprints the same as for manual sprints.

This part explains how sprints are organized in the Execution workspace.

For the organisation in the Requirement workspace, please consult the Synchronize requirements page.

Synchronized Sprints

Display

In Squash, synced sprints are the equivalent of GitLab milestones and iterations (according to the configuration of the synchronization). In the execution library, they are preceded by an icon (Sync, Padlock, or Delete, depending on synchronization status).

Inside those sprints are sprint tickets. They represent GitLab milestone or iteration's issues (only issues included in the perimeter of the configuration are synchronized).

Focus

It is impossible to manually add requirements to a synchronized sprint. Only the perimeter of the synchronization determines which tickets belong to a sprint.

In the execution library, the icon indicates that it is a synced sprint, but also gives information on the synchronization status of the linked GitLab element using the following color code:

  • green icon: the sprint is still updated via synchronization;
  • yellow icon: the sprint is no longer updated via synchronization: one or more GitLab issues are no longer synchronized (for example, the GitLab issue has been moved to another milestone);
  • red icon: the update failed, no element is updated;
  • padlock: the element (milestone or iteration) has been closed in GitLab since last update. This sprint and its content will no longer be updated as long as the element is closed in GitLab (if it is reopened in GitLab, and still falls in the perimeter of the synchronization, it will be updated again);
  • trash: the element has been deleted from GitLab since last update. This sprint and its content will not be updated ever again.

Library synchronization status

Info

The padlock and trash icons in the execution library allows you to see the state of sprints that are not synchronized with GitLab, without having to check its details.

Synchronized sprints status

Synchronized sprints have some information that manual sprints don't:

  • In the Information anchor, GitLab sprint's status is indicated.

Sprint info

The GitLab status is synchronized, and this is what determines whether an issue should be synchronized or not:

  • Upcoming / Open / Expired: the sprint and its tickets will be synchronized;
  • Closed / Deleted: the sprint and its tickets will not be synchronized.

Other actions related to sprint in Squash TM, especially test features, depend on Squash Status.

Modify, move and delete

Synchronized sprints can be moved in the execution library. Again, several behaviors:

  • the sprints are moved into the same project: they will still be updated, at their new location;
  • the sprints are moved into another project: they become manual sprints in the target project and are recreated in the source project during the next synchronization (if they are still in the synchronized perimeter).

When deleting synchronized sprints in Squash:

  • if the sprints are still in the synchronization perimeter: they are recreated with the next synchronization;
  • if the sprints are not in synchronization perimeter anymore: they are not recreated in Squash.

Synchronized sprint tickets

Overview

A synchronized sprint ticket is an issue from GitLab, which is configured for synchronization. In addition to the name, main attributes of the issue are synchronized with values from GitLab (id, category, criticality, status, and description, which includes attachments as links).

Info

CATEGORY, CRITICALITY and STATUS columns are filled according to mappings configured in synchronization.

A synchronized ticket can also exist in Requirement workspace in Squash (as a synchronized requirement), but it is not mandatory.

If an issue is moved in GitLab (e.g. in a new milestone), it will still be at its original location in Squash, but will not be synced anymore. It stays as it was before the last sync update. If its new location in GitLab is still in the synchronized perimeter, it will be synced at its new location in Squash.

Display

The sprint tickets view also shows an icon Sync. It specifies that this is a synchronized sprint ticket, but also gives some information about the sync status of the associated GitLab issue, following this color code:

  • green icon: the sprint ticket is still updated via synchronization;
  • yellow icon: the sprint ticket is no longer updated via synchronization because the matching GitLab issue is no longer in the synchronization perimeter defined in the plugin's configuration, or has been moved in another sprint in the perimeter. If this issue ever gets back in its original element (milestone or iteration) in GitLab, it will be updated again in Squash at its original location (green icon);
  • red icon: the sprint ticket is no longer updated via synchronization because the matching GitLab issue has been deleted in GitLab;
  • black icon: the ticket's synchronization status is unknown (for example, when the global synchronization has failed, or if the milestone has been deleted from GitLab. Its content cannot be synchronized anymore).

Sprint req versions sync status

Delete

If a synchronized sprint ticket is deleted from an unclosed sprint, it will be recreated during the next update.

Focus

If such a deleted ticket is linked to executions, they will also be deleted, definitely. Only the ticket will be recreated during updates.

Target sprint group

Target sprint group corresponds to the sprint group in which GitLab milestones or iterations will be synchronized. The GitLab issues will be synchronized inside these sprints as sprint tickets.

Modify, move, and delete

If the target sprint group is modified (name or description), it will still be updated during synchronizations, and it will keep the new information.

The target sprint group can be moved in the execution library:

  • if it is moved inside the same project: sprints it contains will still be updated;
  • if it is moved to another project: sprints it contains will become manual sprints at their new location.

If the target sprint group is moved to another project or deleted from Squash TM, it will be recreated during the next update (in the original project) if it has not been closed or deleted from GitLab.