GitLab 8.13リリース

私たちは世界中を旅し、ユーザーと会えてとてもうれしいです。

今月は、個人的にもタスクトラッカーを通じても、多くのイノベーションをご紹介できることを誇りに思っています。

これで、複数の発行ボード（発行ボード）を作成し、ボードページにアクセスして、新しいタスクをすばやく作成できます。 マージ競合の寿命は、GitLabで直接解決できるようになったため、さらに難しく一時的になりました。 改善されたCycle Analyticsシステムにより、各環境で実行されているコードのバージョンをさらに簡単に追跡できるようになり、即座にフィードバックが提供されます。

今月のMVPは 、複数のファイルを一度にコミットするためのエンドポイントAPIの作成に貢献したMarc Siegfriedtに授与されます。 マークは、この複雑なマージ要求に取り組むことに忍耐と忍耐を示しました。 マークありがとう！

1つではなく複数のタスクボード（EE）

現在、各GitLab Enterprise Editionプロジェクトには複数のタスクボードを含めることができます。

これにより、タスクのラベルがすべてのボードで同期的に更新されるため、複数のワークフローを管理できます。 たとえば、会社全体のタスクボードと、設計チームのタスクボードがあります。 設計チームがタスクの一部を実行し、タスクをフロントエンドチームに転送すると、両方のボードが更新されます。

タスクボードを見つける方法についてのあなたの話を楽しみにしています。

タスクボードで新しいタスクを直接作成する

タスクボードを表示するときに、リストに別のタスクボードをすばやく追加できます。

もちろん、彼女はすぐに対応するタグを受け取ります。

競合エディターをマージします。

GitLab 8.11はマージ競合の解決を導入しました。これにより、競合を解決するときに、現在のブランチのオプションと現在のブランチにマージするオプションのいずれかを選択できます。

GitLab 8.13には、新しい競合解決ツールが導入されています。 GitLabで競合する変更を直接編集できるようになりました。 つまり、ブラウザページを離れることなく、ほとんどすべての競合を解決できます。

これが、悪夢のようなマージ競合のすべての痛みであるのに役立つことを願っています。

グループタグ

1つの組織と複数のプロジェクトがある場合、多くの場合、複数のタスクボードで同じ優先順位を付けて同じラベルを一度に作成する必要があります。 これはかなり退屈な仕事です。

それを簡素化するために、グループラベルを実装しました。 これらは通常のものとまったく同じように機能しますが、プロジェクトのグループに対して一度作成および構成され、その後各プロジェクトで使用可能になります。

現時点では、グループのページからのみグループタグを作成できます。 将来的には、既存のプロジェクトタグをグループタグに変換する機能を実装します。

レビューアプリを停止する機能

Review Appsを使用すると、レビューとテストのために、すべてのコミットコードを完全に機能する作業環境に展開できます。 現在、このような環境が必要なくなった場合は、GitLabインターフェースから直接停止できます。

デプロイされたバージョンのコードへのリンク

GitLabは、各環境に現在デプロイされているコードのバージョンへの特別なリンク（参照）を作成します。 これらのリンクを単純なgit fetch



で更新するには、ローカルリポジトリを一度セットアップするだけです。

コミットの表示におけるパイプライン

コミットを表示するページに、対応するパイプラインが表示されます。これにより、各コミットで何が発生したかをすぐに確認できます。

サイクル分析の機能強化

Cycle Analyticsの動作が変更されました-現在、すべてのアクティビティは本番環境に送信するだけでなく、一定の期間測定されます。 もちろん、ステージングとプロダクションの段階では、プロダクションに送信されたもののみが表示されます。

マージリクエストの作成者にチケットを割り当てる

コミットまたはマージリクエストで特定のチケットへのリンクを指定しましたが、自分またはマージリクエストの作成者にそれらを割り当てませんでしたか？ これを行う簡単な方法があります：

プロジェクトリポジトリの可視性を制限する

これで、課題やスニペットへのアクセスを制限する既存の機能に加えて、プロジェクトリポジトリへのアクセスを制限できます。 これで、すべてのリポジトリへのアクセスを削除したり、チームメンバーのみにアクセスを許可したりできます。

スラッシュコマンド/ wip

これで、優れたスラッシュコマンドを使用して 、マージリクエストのステータスを/からWork-In-Progress（WIP）にすばやく変更できます。

/wip



と入力して、マージリクエストのコメントまたは説明の送信を確認します。

CIデバッグトラッキング

デフォルトでは、GitLab Runnerはタスクを処理するプロセスに関する情報のほとんどを表示しません。 このアプローチは、スクリプトを使用してコンソールに表示されない限り、アセンブリログの冗長性、およびそれらに入る秘密情報を防ぎます。

一方、このため、タスクの誤った実行の原因を特定することは困難です。 この状況では、 .gitlab-ci.yml



でデバッグトラッキングを有効にできます。このオプションは、バージョン1.7以降のGitLab Runnerで使用できます。 シェルトレースが含まれ、その結果、すべてのコマンドの実行、すべての変数への値の割り当てなどに関する情報がアセンブリログに追加されます。

このオプションを接続する前に、チームメンバーのみがアセンブリログを表示できることを確認してください。 また、すべてのユーザーに対して可視性を再度開く前に、生成されたすべてのログを削除することを忘れないでください。

デバッグ追跡を有効にするには、変数 `CI_DEBUG_TRACEをtrueに設定します。

 job1: variables: CI_DEBUG_TRACE: "true"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細については、デバッグ追跡ドキュメントを参照してください。

CIでのGit操作の無効化

これで、Git操作を無効にして、リポジトリとの対話を必要としないアセンブリを高速化できます。 これを行うには、 .gitlab-ci.yml



でGit戦略を指定し.gitlab-ci.yml



。

 variables: GIT_STRATEGY: none
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CIのGit戦略の詳細については、ドキュメントをご覧ください。

リクエストの展開日をマージ

小さいながらも快適な革新-現在、展開日はマージリクエストに直接示されています。

Gitlabランナー

また、GitLab 8.13では、GitLab Runner 1.7がリリースされました。 最も興味深い変更のリスト：

• Go 1.7の使用を追加-Mac OS X SierraにRunnerサポートを追加！323
• 追加GIT_STRATEGY = none ！332
• 自動スケーリングのOffPeakサポートが追加されました！345
• bash、cmd.exe、powershell.exeでシェルトレースモードを有効にする変数が導入されました！339
• 最初に、InCluster構成がロードされ、ダウンロードが失敗した場合、kubectl ！327 config
• Godep：github.com/Sirupsen/logrusがバージョン0.10.0に更新されました！344
• git clone –no-checkout
  
  
  
  およびgit checkout –force
  
  
  
  使用を追加！341
• ランナーフィールドの値は、GCEとの互換性のために小文字になりました！297制限
• exec execの場合のbefore_scriptの処理を追加！355
• キャッシュエラーが原因でアセンブリに失敗のフラグが付けられなくなりました！359
• 登録手順の改善！356

変更の完全なリストは、 ランナーの変更ログにあります。

Gitlabマターモスト

GatterLab 8.13には、 Mattermostが含まれています。 これは、Slackに代わるオープンソースで、Web、デスクトップ、モバイルデバイスで利用でき、Zapierを使用して700を超えるアプリケーションと統合します 。 今月はSlack、Gitter、XMPP、IRCとの統合が追加されました。 Mattermostは現在、年に6回更新されています。 新しい更新プログラムは、リリースの1か月後にGitLabに追加されます。

APIの革新

このリリースには、APIのいくつかの革新が含まれています。

一度に複数のファイルをコミットする

今月のMVPのおかげで、マークはAPIを介して同時に複数のファイルをコミットできるようになりました。

このトピックに関するAPIドキュメント

タスクボードインターフェース

Andre Guedesは、タスクボード用の完全なAPIを実装しました。 アンドレありがとう！

ユーザーアクション情報

APIを使用して、特定のユーザーがプロジェクトに加えた変更に関する情報を取得できるようになりました。

このトピックに関するドキュメント。

目に見えるプロジェクトのリスト

Ben Boeckelのおかげで、APIを介して表示されるすべてのプロジェクトのリストを表示できるようになりました。

APIドキュメントの詳細

パフォーマンスの変更

CEの変更：

• グループマイルストーンのページ表示パフォーマンスの改善：！6457
• Markdownリンクの処理時に実行されるクエリの数を減らしました：！ 6457および！6545
• Sidekiqは、Railsキャッシュを操作するときにリンクプールを使用するようになりました：！ 6468および！6657
• ci_runners
  
  
  
  テーブルの更新回数を減らし、データベース呼び出しの回数を減らしましたci_runners
  
  
  
  6537
• コミットをプッシュするときに実行されるリクエストの数をわずかに減らしました：！ 6680
• トレンドプロジェクトページのプロジェクトの評価の毎日の予備計算を追加しました。これにより、生産性が向上します！ 6749
• 新しいマージ要求を作成するときの差分の非同期読み込みを追加しました：！ 5844
• 最新のプロジェクト変更のタイムスタンプを変更するとき、Redis一時リンクは使用されなくなりました：！ 6678
• gitlab-shellとAPIのシークレットトークンはメモリに保存されるようになり、すべてのAPIリクエストでディスクから読み取られるわけではありません：！6599
• プロジェクトポリシーをチェックするときに使用されるクエリの数を減らしました：！6442
• ビルドアーティファクトの期限切れに使用されるワーカーは、タスクをより効率的に分散し、より効率的なSQLクエリを使用するようになりました：！6732
• プッシュベースのマージ要求の更新は、特別なSidekiqワーカーを使用するようになりました：！ 6767
• CIパイプラインフックが非同期に更新されるようになりました：！6824
• CIパイプラインメトリックがSidekiqワーカーで更新されるようになりました：！6896
• GitHubブートローダーのパフォーマンスとメモリ使用量が改善されました：！6552
• ディスカッションで絵文字をレンダリングするための最適化されたURL取得。： ！6848
• プロジェクトを作成するとき、データベースからプロジェクトを要求するたびにこれをチェックする（および必要に応じて行を作成する）代わりに、対応するproject_features
  
  
  
  行を自動的に作成します。 これにより、プロジェクトをバージョン2から1に戻す必要があるときにデータベースクエリの数が減ります：！6908
• CIパイプラインコミットは、個々に更新するのではなく、パイプラインを作成した後にのみ更新されます：！6986
• CIパイプラインの継続時間は、状態が変更されるたびに更新されるのではなく、パイプラインの最後でのみ更新されます：！6987
• プロジェクトキャッシュの更新は15分ごとに発生するようになりました。 統計は古くなる可能性があります（たとえば、コミットのカウントなど）が、ディスクの負荷は大幅に減少します：！7017
• Sidekiqは、多数の異なるワーカーに異なるキューを使用するようになりました：！ 7006
• CIパイプラインのタスクはよりスマートに分散されるため、同じパラメーターを持つ複数のタスクを同時に指定することはできません：！7005
• データベース内のマークダウンフィールドのキャッシュ！6095

EEの変更：

• GitLabの使用データがキャッシュされるようになりました：！ 779

gitlab-shellの変更：

• 環境変数を使用してGitパフォーマンストラッキングを有効にできるようになりました：！ 91
• シャード間のリポジトリ移動の改善：！ 97および！96

Omnibus GitLabパッケージの変更

• Jemallocがデフォルトのメモリアロケータとして使用されるようになりました。これにより、使用メモリ量が削減されます。
• バッチNGINXのStatusメソッドがデフォルトで有効になりました。 ルイス・サガストゥムに感謝します！
• gitlab.rbファイルに追加された新しい構成オプション

その他の変更

このリリースには、さまざまなセキュリティ修正を含む他の多くの変更があります。 すべての変更については、変更ログを参照してください。

バロメーターの更新

このリリースには、ダウンタイムを必要とする多数の移行が含まれています。 管理者は、少なくとも30分間のダウンタイムに備える必要があります。 小規模なインストール（たとえば、数百のプロジェクト）では、移行プロセスを5〜10分で完了する必要があります。

これらの推定時間は概算であり、状況によって異なる場合があることに注意してください。

移行の一部：

• 既存のテーブルに外部キーを追加します
• Sidekiqタスクをあるキューから別のキューに移動する
• 重複するラベルを削除する
• ラベルの優先度を設定する
• 他のデータクリーンアップを実行する

Sidekiqキュー

このリリースでは、Sidekiqにいくつかの変更が加えられました。 GitLabでは、 bin/background_jobs



およびOmnibus GitLabでハードコーディングされた限られた数のキューを使用していました。 バージョン8.13以降、使用されるキューの名前はすべてconfig/sidekiq_queues.yml



ます。 bin/background_jobs



を使用してSidekiqまたはOmnibus GitLabを実行するユーザーは、手動で何もする必要がなくなりました。 ソースからインストールを開始するユーザーは、Sidekiqがこの構成ファイルを使用するように設定を変更する必要があります。 これを行うには、Sidekiqが次のように起動することを確認する必要があります。

sidekiq -C path / to / gitlab / config / sidekiq_queues.yml

カスタムSidekiq構成ファイルを使用する場合、 sidekiq_queues.yml



コンテンツをこのファイルに追加する（および最新の状態に保つ）か、 sidekiq_queues.yml



を使用して、 sidekiq_queues.yml



のCLI（コマンドラインインターフェイス）を使用してカスタム設定を定義するsidekiq_queues.yml



あります。

この構成ファイルは、各キューの重みも決定します。 Redisの負荷はわずかに増加しますが、Sidekiqはキューを順番に処理する代わりに、より公平に作業を分散します。 キューの名前と優先順位は、ユーザーが構成できます。

もう一つ

最新バージョンからアップグレードすることを想定しています。 そうでない場合は、スキップする中間更新のバロメーターを確認してください。 GitLabバージョン8.0からアップグレードしていて、CIを有効にしている場合は、最初にGitLab 8.0にアップグレードする必要があります

元のOmnibusパッケージは、更新がどれだけ「大きい」か「小さい」かに関係なく、停止し、移行を開始し、再び開始することに注意してください。 この動作を変更するには、ファイル/etc/gitlab/skip-auto-migrations



追加します。

---

設置

GitLabをゼロからインストールする場合は、 該当するセクションをお読みください。

更新する

私たちのアップデートをお楽しみに。

エンタープライズ版

GitLab Enterprise Editionには、LDAPグループのサポートなどの追加機能が含まれています。 詳細については、 GitLab EEを参照してください。

GitLab EEはサブスクリプションでのみ利用可能です。 新しいツールをインストールして構成するのに十分な時間がありませんか？ サブスクリプション価格には、サーバーにGitLabをインストールおよび更新するためのサービスが含まれています。

英語からの翻訳は、翻訳チーム「Brain and Partners」、 http： //nadmosq.ru、nick_volynkin、rishavant 、およびsgnl_05によって行われました。