6

hudsonのgitプラグインはうまく機能します。ただし、ビルドスクリプトは、リポジトリ内のファイルのバージョン番号を更新し、コミットして、リポジトリにプッシュバックする必要があります。

ハドソンが変更をチェックするために次にポーリングすると、「変更」が再度ビルドされるとコミットが確認され、変更がコミットされるため、再度ビルドされてから、別の変更がコミットされるなど、無限ループに入ります。アイデア。

私はそれを停止し、各リポジトリで「git log」を実行し、gitls-treeHEADを使用して最新のコミットIDがまったく同じであることを比較しました

また、Hudsonは次のコマンドを実行して、変更を確認します。

git fetch + refs / heads / ：refs / remotes / origin / git ls-tree HEAD

Hudson自体がワークスペースリポジトリからコミットをプッシュし、明らかにls-treeの結果が一致するため、このコマンドはどのようにして変更があったかを判断できますか？

ビルドを実行する前にls-treeの結果を保存し、最新のコミットがないものと比較する必要があるようです。ああ。その理論をテストするために、コミットをオフにしてみることができます。

とにかく、Hudsonのgitプラグインの問題を修正するのではなく、ビルドの最後にリポジトリが同一であり、Hudsonがそれを認識できるようにするにはどうすればよいですか。

これを修正する方法は？何か案は？

ウェイン

4

2 に答える 2

5

ビルド システムは、リビジョン管理システムとの書き込み操作を行うべきではありません。これらの変更を自動的にプッシュするべきではありません。

ビルド システムがgit に (たとえば を介して) 現在のリビジョンを問い合わせる場合があります。git describeそれ以外は冗長で、エラーが発生しやすくなります。

考慮すべきもう 1 つのことは、変更をポーリングしないことです。それはばかげた操作方法のようです。(確かに、私はビルドボットのヘビー ユーザーであり、すべてがイベントでトリガーされることに慣れています。)

ポーリングされている git リポジトリは、いつ変更されるかを認識しています。それに基づいて、すぐにビルドを開始するよう CI システムに指示するだけです。ビルドをより早く取得でき、すべてのビルドがトリガーされるため、正当な理由もなく多くの作業を実行しているコンピューターを放置する必要がなくなります。

于 2009-11-21T06:40:33.807 に答える
3

そして答えは…！

Git Hudson プラグインは、この機能を追加するために誰かによってすでにフォークされており、うまく機能します。それでも、ソースを取り下げて、いくつかの小さな問題を修正する必要がありました。

今では美しく動作します。ビルドがコミットされ、Git プラグインは、再び変更されたと考えて、ループせずにリポジトリにプッシュ バックします。

素晴らしい！

他の誰かがこれを必要とする場合は、Github.com で Hudson-GIT-Plugin の tickzoom フォークを探しますが、メイン プロジェクトに既に統合されているかどうかを確認してください。コミッターは、興味があり、フォークを組み合わせることを計画していると述べました。

ウェイン

于 2009-11-21T20:47:43.623 に答える