問題タブ [go-cd]

いずれかのプロジェクトで、Thoughtworks Go で次のエラーが表示されます。これは何を意味し、どのように修正すればよいですか?

マテリアルの変更チェックに失敗しました: URL: https://username :*******@bitbucket.org/company/project.git、Branch: [Mar-03 17:08:55] コマンドの実行中にエラーが発生しました: ---コマンド --- git rev-parse --abbrev-ref HEAD --- 環境 --- {} --- INPUT ---- --OUTPUT --- HEAD --- ERROR --- STDERR: 致命的: 曖昧引数 'HEAD': 不明なリビジョンまたはパスが作業ツリーにありません。STDERR: '--' を使用して、次のようにパスをリビジョンから分離します: STDERR: 'git [...] -- [...]' ---

継続的インテグレーション ツールとその利点に関する調査を行っています。私の研究では、次のツールを見ています。

1. GitLab CI
2. ジェンキンス
3. 竹
4. GoCD
5. チームシティ

今、私はすべての要件と利点であなたを悩ませることはありません. しかし、これまでのところ、これらを除いてツール間の違いはそれほど多くありません。

1. ファンイン ファンアウト サポート GoCD
2. コミュニティの規模、Jenkins と GitLab が最も多くの貢献者を持っているようです
3. 費用
4. オープンソースかどうか
5. 利用可能なプラグインの量

継続的インテグレーション ツールを選択しなければならなかった一部の人々が、そこでの経験とそのツールを選択した理由を共有できるかどうか、また、カバーしなかったものを選択する前に検討する価値のある特定の違いがあるかどうかを知りたいと思っていました。

ファンイン ファンアウトのサポートと継続的デリバリー パイプラインの視覚化により、現在 GoCD に傾倒しています。このツールの問題をサポートした経験のある人はいますか?

よろしくお願いします。

パッケージの展開に使用していますが、.in を削除するGoCD方法があれば教えてください。Stage HistoryGoAgent

これを尋ねているのは、パイプラインのテスト中にステージ ラベルがある程度増加していたため、自動デプロイの正確な数を取得できなかったためです。

プロセスを混乱させることなく、すべてのステージ履歴を削除できるかどうか誰か教えてもらえますか?

パイプライン用に複数の git マテリアルがあるため、作業ディレクトリを追加する必要があります。gradle プラグインには作業ディレクトリがないため、gradlew または build.gradle が見つかりません。これを回避する方法はありますか。

Windows OS で実行するアプリケーションと、Centos/Ubuntu などの Linux で実行するアプリケーションを構築しようとしています。パイプラインの設計中に、Windows 関連のすべてのタスク/ジョブが Windows エージェントに送られ、Linux 関連のすべてのジョブが適切な Linux OS に送られるようにする方法を教えてください。

これを達成するための理想的なアプローチは何でしょうか。

mvnコマンドを実行すると生成されるすべてのアーティファクトのすべての GroupID:ArtifactID:Version (GAV) のリストを表示する (サポートされている) ベースのコマンドを探していmvn packageます。

親 pom のない単一モジュールの Maven プロジェクトの場合、これは簡単です。pom の内部を見ることができます。

親 pom を持つ単一モジュールの Maven プロジェクトの場合、要素help:effective-pomが存在する pom ファイルを使用できます。<version>

マルチモジュールMavenプロジェクト（リアクター）の場合、実際に同じことができます（そうは思わなかったので、今試してみて学んだことです）。<project>これにより、(複数の)要素のファイルを解析できます。

他に考慮すべきことはありますか？

これの全体的な目標は、ダウンストリームの継続的デリバリー ( http://go.cd/ ) ステージ/ステップ/ジョブに、アップストリームの依存関係のどのバージョンを使用する必要があるかに関する情報をフィードできるようにすることです。