2016-09-14 11 views
0

私は大規模なプロジェクト(パイプライン)の一部であり、かなり頻繁に一緒にテストする必要があるたくさんのプロジェクトに取り組んでいます。手作業によるテストはそれほど大きくないので、今後Gradle + Jenkins CIを使ってテストを進めることにしました。私の最初のテストは成功し、ユニットテストなどは素晴らしく実行されており、JenkinsはJARファイルを構築しています。Gradle/Jenkins JARがGitHubにリリース

私のすべてのプロジェクトはオープンソースでGitHubで利用できるので、それぞれの(サブ)プロジェクトのGitHubリリースページに公開するように設定したいと思います。私が開発し

  • 、ジェンキンスは、フックを経由して、これを見て、物事を構築するのGradleスクリプトを実行し、成功したテスト時に新しいに私のプロジェクトで作成したJARファイルを公開するGitのタグ
  • にコミット:このような何かGitHubのリリース版

残念ながら、これは期待どおりに動作していません。 Plugin hereを使用します。これは、たとえば、JARファイルではなく、パッケージ化されたソースコードをプッシュするだけです。さもなければ、これはうまくいくと私は何かを見過ごしたかもしれない?

誰かがこれに関する経験がありますか?

+1

生成されたJARファイルをコードと一緒にGitリポジトリにプッシュする必要があるのはなぜですか?あなたのGitリポジトリにjarファイルなどの重いファイルをプッシュするのは良い習慣ではないことに注意してください。代わりに、[Artifactory](https://www.jfrog.com/open-ソース/)... – Pom12

+0

こんにちはPom12 - 私の最初のコメントは十分に具体的ではなかったと思います。ビルドされたJARファイルを自分のリポジトリにコミットするのではなく、エンドユーザ向けのJARファイルをリリースするGitHubのプロジェクトの「リリース」セクション。もちろん、私はBintrayに頼ることができますが、ビルドされたJARをエンドユーザーの見やすさを向上させるためにプロジェクト特有のリリースセクションにプッシュしたいと思っています。 – w3b1x

答えて

0

Github releaseが間違っていると思います。 Githubの観点からは、リリースはあなたのarfifactを展開するいくつかのフォルダではありませんが(例えばビルドされたJar)、基本的には特定のコミットを指し示すGitタグであり、 "ok、私はこのコミットを考慮しますd215465454私のリリース1.2.3 "コミットのポインタに過ぎないので、特定のリリースのGitヒストリをいつでも見つけることができます。詳細については、Git excellent Tagging documentationをご覧ください。

さらに、実際のjarファイルをエンドユーザーに公開する必要はありません。代わりにBintrayやArtifactoryを使用して実際のjarファイルを展開し、エンドユーザーが自分のjarに依存するようにgradleビルドファイルを設定することができます。

関連する問題