最新情報

このセクションでは、リリース2020.1のSwarmで導入された主な変更点の概要について説明します。 詳細については、ディストリビューションのRELNOTES.txtファイルを参照してください。

主要な新機能

Swarmの折りたたみ可能なサイドメニュー

元のSwarmのトップメニューはページの左側に移動され、折りたたむことでスペースを節約できます。 例えば、プロジェクトを入力すると、メインメニューがプロジェクトメニューに置き換えられるため、よりコンテキストに対応しています。

詳細については、「メインツールバーとプロジェクトタブバーのクイックリファレンス」を参照してください。

Swarm UIから直接テキストファイルを編集する - テクノロジープレビュー機能

テキストファイルをすばやく編集して、変更を保留状態またはコミットする必要がある場合、 Swarmでは、Swarm UIの[File]ブラウザビューから直接テキストファイルを編集できるようになりました。

Swarm UIでグローバルワークフローを編集する

Swarmのワークフローページで、グローバルワークフローを編集できるようになりました(グローバルワークフロールールを参照)。 旧バージョンのSwarmをアップグレードすると、既存のワークフロールールが自動的に新しいUIに移行されます。

Swarm UIでテストを作成する

Swarm UIでテストを作成し、新しいテストメニューで表示できるようになりました。詳細については、「テスト」を参照してください。

ワークフローにテストを追加する

Swarm UIで構成されたテストは、個々のワークフローに関連付けることができます。 テストが含まれているワークフローにレビューが関連付けられている場合、レビューの作成時、更新時、送信時にそれらのテストが実行されます。詳細については、「ワークフロー」を参照してください。 また、テストはグローバルワークフローに関連付けることもできます。これにより、テストがプロジェクトに含まれていない場合でも、すべての変更に対してこれらのグローバルテストが実施されます。

その他の新機能

新しい[キャッシュ情報]タブ

[システム情報]ページの新しい[キャッシュ情報]タブで、SwarmのRedisキャッシュの確認と管理を行うことができるようになりました。 ボタンをクリックするだけで、キャッシュの検証やSwarm構成の再ロードを行うことができます。

重要な情報

CentOS 6とRHEL 6に対するSwarmサポートの変更

Swarm 2020.1は、SwarmにCentOS 6とRHEL 6をインストールできる最後のSwarmバージョンです。 これは、サポートされているテクノロジープラットフォームへの移行に伴う変更です。

Helix Coreサーバ 2020.1のストリーム仕様ファイルの権限の変更

バージョン2020.1以降のHelixサーバでは、Swarmでストリーム仕様ファイルの編集と表示を行うための権限が変更されました。 SwarmユーザがSwarmでストリーム仕様ファイルの表示や編集を行うには、ディポ全体(//...)に対するadmin 権限が必要です。

Swarm 2020.1のトリガスクリプトの更新

swarm.shelvedel shelve-delトリガスクリプトがSwarm 2020.1で更新されました。このトリガスクリプトが存在しない場合は、このトリガスクリプトを追加するか、Helixサーバのトリガテーブルでこのトリガスクリプトを更新する必要があります。詳細については、 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。を参照してください。

Swarm 2020.1以降でのカスタムモジュールのサポート

Zend 3 Frameworkプロジェクトが、Laminasというオープンソースプロジェクトに切り替わりました(https://getlaminas.org/about/を参照)。 Swarm 2020.1では、Laminas Frameworkが使用されています。これは、これまで使用していたバージョンのプラットフォームがサポート終了(EOL)になったことに伴う変更です。

バージョン2019.3以前のSwarm用に作成されたカスタムのSwarmモジュールを使用している場合は、それらのモジュールをアップグレードしてLaminas Frameworkに対応させる必要があります。 ZendカスタムモジュールをLaminasモジュールに更新する方法については、既存のカスタムモジュールをLaminas Frameworkにアップグレードするを参照してください。

バージョン2019.1以前のSwarmのアップグレード

Swarm 2019.2では、Helix Coreサーバの負荷を軽減してパフォーマンスを改善する目的で、Redisメモリ内キャッシュが導入されました。 これに伴い、Swarmで使用されていたファイルベースのキャッシュが廃止されました。

多数のユーザ、グループ、プロジェクトが存在するSwarmシステムの場合、新しいキャッシュに初めてデータを取り込む際に時間がかかることがあります。 大規模なSwarmシステムを使用している場合は、Swarmのインストールやアップグレードを行う前に、Redisサーバの接続オプションと設定オプションを確認する必要があります(Redisサーバを参照)。

Swarm 2019.2に対するワークフロー機能のサポートの変更

Swarmのワークフロー機能は、デフォルトで有効になっています。 以前のバージョンのSwarmをアップグレードする場合は、トリガを更新する必要があります。詳細については、Swarmのアップグレードを参照してください。

Swarm 2019.1でサポートされるPHPとApacheのバージョンが変更されました。

Swarm 2019.1では、バージョン7.0よりも古いPHPのサポートが廃止されました。 この変更の結果、Apache 2.2のサポートも廃止されました。 これは、サポート終了(EOL)になったバージョンのプラットフォームを使用しないようにするための措置です。

Swarm 2019.1にアップグレードする前に、サポート対象のバージョンのPHPとApacheをインストールできることを確認してください。 SwarmでサポートされるPHPとApacheのバージョンについて詳しくは、PHPとApache webサーバを参照してください。

Swarm 2019.1以降には、P4PHP 2019.1以降のバージョンが必要です

P4PHPの最新バージョンは、Swarmパッケージ、OVA、およびtarballのインストールに含まれます。

既知の制約事項

HelixサーバがWindows上で稼働している状態でコマンドラインを使用してシェルフを削除した場合、Swarmのshelvedeトリガが失敗することがある

以下の場合、Swarmのshelvedelトリガが失敗します。

HelixサーバがWindows上でホストされている状態で、いずれかのローカルドライブのルートディレクトリでシェルフ削除コマンドを実行した場合。

例えば、c:\p4 -u bruno -c my_shelf shelve -d -c 9コマンドを実行した場合です。

Swarm 2019.2以降のユーザ名とグループ名で使用できない文字

バージョン2019.2以降のSwarmでは、ユーザ名とグループ名で次の文字を使用することはできません: :@{}()

Swarm 2019.1以降の「ストリームのプライベート編集」機能に対するHelixサーバのサポート

サポート: ワークスペースでストリームのプライベート編集機能を使用して、ストリーム仕様を編集することができます。

サポートされていない: ロックされたストリーム仕様をSwarmでコミットすることはできません。

単一のSwarmインスタンス上の複数のHelixサーバインスタンス

問題: <swarm_root>/data/config.phpファイルのenvironmentブロックでbase_url構成可能変数の値を変更すると、Helixサーバに対するSwarmの接続がすべて失われます。 この場合、システムの動作が停止します。

解決策: base_url構成可能変数を<swarm_root>/data/config.phpのenvironmentブロックから削除します。

グローバルダッシュボードはMFAログインをサポートしていません

問題: SwarmでMFAを有効にしている場合、グローバルダッシュボードからサーバインスタンスにログインできない。

回避策: URLにサーバインスタンス名を含めて各インスタンスに個別にログインする(例: https://swarm.company.com/serverA)。

最上位のビューで、Helixサーバの一部のコミットがプロジェクトの[コミット]タブに表示されない場合がある

プロジェクトの[コミット]タブの最上位のクライアントビューは、プロジェクト内のすべてのブランチによって構成されています。

 

例えば、「Alpha」というプロジェクトが以下のブランチによって構成されているとします。

 

ブランチ: QA:

//depot/alpha/dev/QA/...

 

ブランチ: Dev:

//depot/alpha/dev/...

-//depot/alpha/dev/QA/...

 

作成順にブランチを処理し、それらすべてのブランチで先頭のパスから順に処理することにより、プロジェクトの[コミット]タブのビューが生成されます。

上記のAlphaプロジェクトの場合は、以下のような動作になります。

最初のパスでは、//depot/alpha/dev/QA/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューに表示されます。

2番目のパスでは、//depot/alpha/dev/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューに表示されます。

3番目のパスでは、//depot/alpha/dev/QA/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューから除外されます。

 

結果: QAブランチで表示されるはずの、//depot/alpha/dev/QA/に対するコミットが、プロジェクトの[コミット]タブの最上位ビューに表示されなくなります。

 

ブランチが単純な構成になっている場合は、ブランチを作成する際に上記の例を考慮することにより、この問題を回避することができます。 上記の例では、Devブランチを作成してからQAブランチを作成すると、//depot/alpha/dev/QA/ディレクトリがプロジェクトの[コミット]タブの最上位ビューから除外されることがないため、この問題を回避することができます。

Swarm OVAのインストールで「Run p4 login2」というエラーが発生する

問題: MFAが有効になっているHelixサーバに対してSwarm OVAをインストールすると、「Run p4 login2」というエラーが発生してインストールが失敗します。

回避策: Swarm OVAをインストールする前に、MFAが有効になっているsuperユーザアカウントに対してp4 login2コマンドを実行する必要があります。 p4 login2コマンドの詳細については、Helix Core P4コマンドリファレンスの「p4 login2」を参照してください。

タスクストリームのレビュー

タスクストリームのプリコミットレビューはまだサポートされていません。