web-dev-qa-db-ja.com

再帰的なDrushメイク、さまざまなgitブランチでの作業

セットアップ

すべてのサイトでカスタムを作成しますDrupalインストールプロファイルが作成され、そのコピーはdrush makeを使用して構築されます（Aegirを使用しますが、違いはありません）。

ダウンロード用のトップレベルのビルドmakefileがあり、Drupalコアとインストールプロファイルがあり、インストールプロファイルには、ダウンロードする機能を指定するmakefileが含まれており、それぞれに依存関係を指定するmakefileがあります（カスタムプライベートgit reposまたはcontribモジュールのモジュール）。

ビルドmakefile（build-SITENAME.make）は、次のようにインストールプロファイルを指定します。

projects[SITENAME_profile][type] = profile
projects[SITENAME_profile][download][type] = git
projects[SITENAME_profile][download][url] = git.hostname:drupal-sites/SITENAME_profile

次に、インストールプロファイルのメイクファイルで、ダウンロードする一連の機能を指定します。次に例を示します。

projects[blog][type] = module
projects[blog][subdir] = features
projects[blog][download][type] = git
projects[blog][download][url] = git.hostname:drupal-features/blog

その後、カスタムモジュールやcontribモジュールなどがダウンロードされます。

上記の設定は数年間うまくいきました。

問題

この問題は、gitブランチを使用して開発のさまざまな段階を管理しようとすると発生します。開発、ステージング、および生産。 CIが自動的に各ブランチのDrupalサイトを管理します。開発ブランチでビルドがトリガーされた場合、drush makeは、ダウンロードするリポジトリごとに正しいブランチを取得する必要があります。

マルチリポジトリと再帰的なmakefile構造を考えると、drush makeを使用してgitリポジトリから正しいブランチを再帰的にダウンロードするにはどうすればよいでしょうか。

すでに試したこと

  1. drush makeを使用すると、gitブランチからのダウンロードが可能になります。たとえば、メイクファイル（ビルド、インストールプロファイル、および機能リポジトリ）ごとに、次のような行が追加されます。

    projects[blog][download][branch] = development

    ダウンロードされるリポジトリのブランチが、メイクファイルが置かれているリポジトリのブランチと一致すると、「ブログ」機能の開発ブランチで指定されたカスタムモジュールが、そのモジュールの開発ブランチからダウンロードされます。すごい！

    ただし、これにより、Makefileを含むリポジトリのブランチをマージする際に問題が発生します（セットアップが非常に多い場合）、誤って[branch] = developmentをそれらのマスターにマージしないように非常に注意する必要があります。

  2. Gitリポジトリダウンロードのデフォルトブランチを指定するコマンドラインオプションについては、drush makeドキュメントを確認してください。何も見つかりませんでした。
  3. 同様の難問を持つ人々をインターネットで検索したところ、多くの人がプロジェクト全体のすべての依存関係を単一のmakeファイルにダンプしているようですが、これはフィーチャーのモジュール性を壊します。

注：私は投票したり、議論を求めたりしていません。私は抜けている何かばかげたことや、何かeveryoneが他にあると私は信じています。

version-controldrushaegir
3
user4301448

これは素晴らしい質問です！私はAegirとDrush Makeの両方を維持していますが、あなたに本当に良い答えがあるかどうかはわかりません。

  1. （1）の提案は、おそらく現時点で最善の策だと思います。あなたが述べたように、それはすでに働いているという長所を持っています。ただし、これらの[branch]属性を誤ってマージする問題は依然として有効です。ただし、解決策はDrush Makeではなく、Gitにあります。

    これをチェックしてください 記事 。 Git属性とカスタム（null）Gitマージドライバー。要約すると、各開発者は以下を実行する必要があります。

    git config --global merge.ours.driver true

    これは基本的に、アイテムが 'ours'マージドライバーを使用するようにフラグが設定されている場合、/bin/trueを呼び出すだけなので、 null操作であることへの参照。

    しかし、このドライバを使用するようにメイクファイルにフラグを付けるにはどうすればよいですか？これがGit属性の出番です。リポジトリのルートに.gitattributesファイルを作成します（つまり、.gitignoreと一緒に）。次に、次の行を追加します。

    build-SITENAME.make merge=ours

    機能リポジトリにも同じことをしたいと思うでしょう。

  2. Drush Makeを活用したソリューションについては、確実なソリューションがあることを知りません。

    数年前、 Drush Makeのドキュメント で説明されているように、オーバーライドを使用して同様のことを試みました。基本的な考え方は、含まれているメイクファイルから属性を変更（オーバーライド）できるということです。

    ただし、再帰的なメイクファイルの場合は、ビルド前に親のメイクファイルにマージされるのではなく、個別にビルドされます。その結果、それらの属性をオーバーライドする機会はありません。これは私がテストしてから時間の経過とともに変わった可能性がありますが、基礎となるメカニズムはほとんど同じままであるため、機能しない可能性があります。

    親makefileに default を設定することも、このようなことを実現する良い方法です。私はこれをテストしていませんが、繰り返しになりますが、デフォルトが再帰的に構築されたmakefileに適用されないことは確かです。

    代わりに、再帰なしで親makefileをビルドするオプションがあり、機能makefileを直接インクルードします。 include makefiles をGitリポジトリ内から直接（新しいYAML構文を使用して）できるようになりました。

    includes:
  # A file from a git repository.
  makefile: "example_dir/example.make"
  download:
    type: "git"
    url: "[email protected]:organisation/repository.git"
    branch: "master"

    drush makeオプションを指定して--no-recursionを呼び出すか、メイクファイルで指定する必要があります。

    --no-recursion                   Do not recurse into the makefiles of any
                                 downloaded projects; you can also set 
                                 [do_recursion] = 0 on a
                                 per-project basis in the makefile.

他にも利用可能なオプションがあると思いますが、これらは既存のワークフローに最も影響を与えないと思うオプションです。他の提案を見てみたいと思います。

。makeファイルでの変数の使用 を許可する機能のリクエストがあります。これにより、このようなユースケースが実装された場合に、より直接的に対処できるようになります。おそらく、コマンドラインで渡されたオプションや環境変数でこのような変数を探すことができます。

そうは言っても、長期的には、Drush MakeはComposerに完全に取って代わられると思います。そのため、上記の提案がうまくいかない場合は、その方向で検討する方が実り多いかもしれません。

2
ergonlogic

composer を使用することを検討してください。これは、再帰的な依存関係を設定する依存ツリー全体を分析できるため、再帰的な依存関係に関して少し柔軟になる可能性があります。

例を見る composer.json ：

...
    "require": {
        "composer/installers": "^1.0.20",
        "drupal/core": "8.0.*",
        "drush/drush": "8.*",
        "drupal/console": "~0.8",

        "drupal/devel": "8.1.*@dev",
        "drupal/token": "8.1.*@dev"
    },
...

見る：

1
kenorb

異なるブランチの管理に興味がある場合は、これが [〜＃〜] ads [〜＃〜] ディストリビューション（ GitHub ）でどのように実現されるかを確認してください。

基本的に、特定のブランチに適切なファイルをロードするようにCIをセットアップできます。例：

build-SITENAME-BRANCH.make

このファイルには、特定のブランチの特定のコンポーネント（例：プロファイル）を含めることができ、その他すべて（例：一般的な投稿モジュール）を異なる.makeファイル（includes[] = contrib.make）から含めることができます。参照： build-ads-latest-dev.make 。

これで問題が解決しない場合は、代わりに、適切なブランチを設定するビルドを実行する前にインプレース編集を使用します。

たとえば、ブランチを指定する次の行があるとします。

projects[foo][download][branch] = master

次の方法で変更できます。

ex -s +"%s/master/develop/" -cwq build-SITENAME.make
1
kenorb