What's new in Swarm 2018.2

This section provides a summary of the notable changes in Swarm for the 2018.2 release. Full details are available in the distribution's RELNOTES.txt file.

Important information

Upgrade process changed

The upgrade process changed for Swarm version 2017.3 and later.

PHP version support change from Swarm version 2019.1

We are planning to remove support for versions of PHP older than 5.4 in Swarm 2019.1. This is part of our commitment to move away from using versions of platforms that have reached End-of-Life (EOL).
This means that you will need to ensure that you can install PHP 5.4 or greater when Swarm 2019.1 becomes available.

New trigger script added for Swarm 2018.1

A new trigger script called swarm.shelvedel shelve-del has been added, this is a prerequisite for the new process_shelf_delete_when configurable. The trigger script must be added to the Helix Servertrigger table.
Swarm checks for a supported Helix Server version when you install or upgrade Swarm. If a supported version of Helix Server is not found the swarm.shelvedel shelve-delete trigger and process_shelf_delete_when configurable are not supported, see Helix Server requirements.

New trigger scripts added for Swarm 2018.2

The swarm.enforce change-submit, swarm.strict change-content, and swarm.shelvesub shelve-submit trigger lines were added in Swarm 2018.2, these are a prerequisite for the new Swarm Workflow technology preview feature.
If the Workflow feature is enabled, the trigger lines must be added to the Helix Server trigger table. Any earlier enforce and strict triggers must be commented out, see setup the trigger table.

Major new functionality

New Project page
The new Project page enables you to view, search, create, edit, and delete projects. For more information about the project page, see Projects.
Exclusionary mapping for project branches
Project branches now support exclusionary mapping, see branch mapping.
Moderator behavior when a review spans multiple branches
Swarm administrators can now specify the moderation logic when a review spans multiple branches that have moderators. By default, only one of the moderators from any one of the branches needs to approve the review but this can be configured so that reviews require one moderator from each branch to approve the review. For instructions on configuring moderator behavior, see Moderator behavior when a review spans multiple branches.
Minimum up votes
You can now set the minimum number of up votes reviews require before they can be approved. Minimum up votes is set on projects and branches.
Protected end states
You can now stop review content being changed if it is in a review state that is considered complete. The review states that are considered complete are set by the administrator, see Protected end states.
Retain default reviewers
Prevent default reviewers being removed from reviews associated with projects and branches with Retain default reviewers enabled, see Retain default reviewers.
Obliterate review
Users with admin or super user rights can now obliterate a review. Obliterate is used to permanently delete reviews that have been created by mistake. For instance, if a review is associated with the wrong changelist or a review contains sensitive information that should not be openly available. For more information about obliterating reviews, see Obliterate review.

Minor new functionality

New trigger configuration items
TIMEOUT (optional): configure the number of seconds to wait before returning an error when communicating with the Swarm server.
IGNORE_TIMEOUT (optional): configure the action to take if communication with the Swarm server times out. For example, if you are submitting a large number of files to the Helix Server.
IGNORE_NOSERVER (optional): configure the action to take if communication with the Swarm server fails. For example, the Swarm server is down.
For more information about the new trigger configuration items, see Configuration items.
New dashboard link
The dashboard is now accessed from the Swarm logo on the left of the main toolbar.
The project sidebar has been removed from the dashboard page, projects now have a dedicated page. For an overview of the projects page, see Projects.
New help link
The Swarm help documentation is now available from the Help Help link button to the right of your userid on the main toolbar.
Fixed Project file browser view
Directories and files are now displayed in the correct folder structure when browsing files with the project file browser. For instructions on how to use the project file browser, see Project Files tab.
Fixed review ZIP download structure
When downloading files in a review using the Download .zip button, the content of the Zip archive now has the correct folder structure. For instructions on how to download files in a review as a zip file, see Download .zip button.
New API endpoints
A number of new endpoints have been added to the API. See the Swarm API.

Technology preview features

Warning

Technology preview features:

Technology Preview features are currently unsupported, might not be functionally complete, and are not suitable for deployment in production. Technology preview features are subject to change and may be removed before they become fully supported features.

These features are provided to the customer to solicit interest and feedback, with the goal of full support in future releases. Customers are encouraged to provide feedback and functionality suggestions for Technology Preview features before they become fully supported.

Workflow

Workflow is a technology preview feature and is disabled by default.

Workflow rules
Swarm users can now create and manage workflows to ensure that changelists and code reviews in a project/branch follow the rules specified in that workflow. See Workflow overview.
A workflow is made up of a combination of the following rules (see Workflow rules for full details):
On commit without review: determine what happens when a changelist is committed without a review. Allow the commit, automatically create a review, or reject the commit.
On commit with a review: determine what happens when a changelist is committed with a review. Allow the commit or reject the commit unless the review is approved.
On update of a review in an end state: stop a review from being changed if it is in a review state that is considered complete. The review states that are considered complete are set by the administrator. Allow the review to be changed, or reject the change.
Count up votes from: define whose up votes count towards the Minimum up votes value set on the project/branch the review is associated with. All up votes count or only project member up votes count.
Automatically approve reviews: enable automatic approval of a review when all of its voting requirements are satisfied. Never automatically approve a review or automatically approve review.
Global workflow rules
Swarm administrators can now enforce individual workflow rules on projects/branches without an associated workflow or enforce a minimum workflow on the entire Helix Core Server. For more information about global workflow rules, see Workflow global rules - Technology preview feature.
New Workflow trigger scripts added in Swarm 2018.2
The swarm.enforce change-submit, swarm.strict change-content, and swarm.shelvesub shelve-submit trigger lines were added in Swarm 2018.2, these are a prerequisite for the new Swarm workflow rules.
If the Workflow feature is enabled, the trigger lines must be added to the Helix Server trigger table. Any earlier enforce and strict triggers must be commented out, see setup the trigger table.

Workflow caveats

Possible performance issues on large Swarm systems
The Workflow technology preview feature has not been fully optimized and tested on Swarm systems with a large number of projects, branches, and paths.
Workflow trigger scripts have different functionality to the previous strict and enforce triggers
Trigger types checkenforced, checkstrict, and checkshelve were introduced in Swarm 2018.2 for the Workflow technology preview feature. The workflow triggers do not support the following trigger functionality available in Swarm 2018.1 and earlier:
To continue to use this functionality, you must keep your existing enforce and strict triggers and leave the Workflow technology feature disabled.

Known limitations

Access Control
Swarm maintains a variety of information in the Helix Core Server's keys facility. By default, users with list-level privileges can read these keys, which can include comments that contain excerpts of code they may not normally have access to.
The Helix Core Server, version 2013.1/659207 or higher, has a configuration setting to require admin-level privileges for access to read and write keys. See Hiding Swarm storage from regular users.
Task Stream Reviews
Pre-commit reviews in a task stream are not yet supported.
Swarm OVA installation fails with a Run p4 login2 error
Issue: Swarm OVA deployment against an MFA enabled Helix Server fails with a Run p4 login2 error.
Workaround: You must run p4 login2 for a super user account that has MFA enabled before deploying the Swarm OVA. For p4 login2 detail, see p4 login2 in P4 Command Reference.
Zip file does not include files marked for Add
Files Marked for Add in pre-commit reviews and shelved changelists are not included in the zip file.
Project Commits tab can fail to show some Helix Server commits in the top level view
The Project Commits tab top level client view is made up of all of the branches of the project.
 
For example, Project Alpha:
 
Branch: QA:
//depot/alpha/dev/QA/...
 
Branch: Dev :
//depot/alpha/dev/...
-//depot/alpha/dev/QA/...
 
The project commits tab view is generated by processing the branches in the order that they were created in and from top to bottom for the paths in each of those branches.
For the project Alpha example above:
The first path includes all of the directories and files under //depot/alpha/dev/QA/ in the project commits tab top level view.
The second path includes all of the directories and files under //depot/alpha/dev/ in the project commits tab top level view.
The third path excludes all of the directories and files in //depot/alpha/dev/QA/ from the project commits tab top level view.
 
Result: commits made to //depot/alpha/dev/QA/ that should be shown for the QA branch are not displayed in the Project Commits tab top level view.
 
When you have a simple branch structure this can be avoided by considering this issue when you create your branches. In the example above, creating the Dev branch first and then creating the QA branch avoids the problem because//depot/alpha/dev/QA/ is not excluded from the ProjectCommits tab top level view.
Tip

Individual branch views display the commits correctly.