問題タブ [hudson]

内部アーティファクトリポジトリがあります。現時点では、すべてのスナップショットがそこに展開されます。また、Web インターフェイスを備えた別のサーバーが必要であり、作成されたアーティファクトをそこにコピーしたいと考えています。

私たちのビルドでは Hudson を使用していますが、ビルド後のアクション「アーティファクトを Maven リポジトリにデプロイする」が scp と一緒に機能しません。したがって、他のエレガントな方法でそれを行うという問題があります。Maven が複数の配布リポジトリを持つことができないのはなぜですか? 何か案は？

Artifactory が (自動!) 新しい展開のたびに標準の Maven リポジトリへの増分エクスポートをサポートする場合は、最も良いことです。

Hudsonを使用した自動ビルドの一部として-lib引数をantに渡そうとしていますが、これを行う方法がわかりません。関連するライブラリをant/libフォルダーに追加することもできますが、その場合、同じバージョンのライブラリがそのマシン上のすべてのビルドで共有される必要があります。

どんな助けでも大歓迎です。

フレックス プロジェクト用の CI 環境のセットアップを検討しています。このような環境をセットアップした経験はほとんどありませんが、それについて多くのことを読み、私たちのプロジェクトでこれから多くの利益を得ることができると考えています. 私は ANT の経験があり、現在、建物に使用しています。私はしばらく Hudson を検討してきましたが、適切な CI 環境をサポートする力を持ちながら、非常に素晴らしくシンプルに見えます。

基本的に、私の質問は、Hudson で Flex プロジェクトをセットアップした経験のある人はいますか? もしそうなら、ハドソンを立ち上げて実行するためにプロジェクトごとにどのような労力が必要か、問題、コスト/メリットに関する情報を共有してください. 私はしばらくの間グーグルで検索しましたが、誇らしげに言えば、Fast 字句解析器とハドソン川の両方について詳しく知っていますが、この投稿のトピックについてはほとんど詳しくありません =)

ruby スクリプト経由でビルド結果を hudson に送信したいと考えています。私が見つけることができる小さなドキュメントは、タグ内のデータが「hexBinary」形式であると述べています。「Hello, world」のような単純なルビ文字列を取得して、その形式に変換するにはどうすればよいですか?

私たちは、Java Swing プロジェクトのビルド サーバーとして機能する Hudson マシンを使用しています。ビルド プロセスは Ant スクリプトに基づいています (Maven ではありません)。

QuickTest Professional からテストを統合した人はいますか?

つまり、Ant を介して qtp テストを自動的に実行することは可能ですか?

私は以下を実行しようとしました：

しかし、それはlsを見つけられません（たとえそれがWindowsパス上にあるとしても）。これを設定する方法はありますか？

更新：言い換えると、このページでPythonの使用方法を示すように、Windowscmdの代わりにcygwinbashを使用するビルドステップを設定できるようにしたいと思います。

ハドソンスレーブで実行されているプロジェクトがいくつかあります。そのうちの 1 つで、デフォルト (私の環境では Java5) ではなく、Java6 で Ant を実行したいと考えています。

プロジェクト構成ビューで、次のいずれかを見つけたいと思っていました。

• このプロジェクトに使用するカスタム JDK の場所を設定できる明示的なオプション。
• このプロジェクトのカスタム環境変数を設定する方法。これにより、JAVA_HOME を JDK6 の場所に設定できます。これにより、Ant が必要に応じて Java6 で動作します。

上記のいずれかを行う方法はありますか？それらの施設の 1 つが利用可能である場合、アクセス方法がわかりません。Hudson 1.285で実行しています。

可能であれば、「Ant の呼び出し」操作の代わりに「シェルの実行」操作を使用することは避けたいと思います。私のスレーブは z/OS 上にあり、Hudson はこのプラットフォームで一時的なシェル スクリプトを適切に作成していないようです (おそらくエンコーディングの問題)。 ）。

バッチタスク プラグインを使用して内部リポジトリに Maven リリースを行うように Hudson をセットアップしています。私はそれをやっています：

人々が使用した他の方法と、それらの方法の長所と短所に興味があります。また、人々が遭遇した落とし穴。

リポジトリ URL、ユーザー名、およびパスワードを入力すると、次のエラーが表示されます。

誰もそれを修正する方法を知っていますか?

認証は試行されませんでした。失敗: svn: 操作がキャンセルされました

org.tmatesoft.svn.core.SVNCancelException: svn: hudson.scm.SubversionSCM$DescriptorImpl.postCredential(SubversionSCM.java:1421) で hudson.scm.SubversionSCM$DescriptorImpl.doPostCredential(SubversionSCM.java:1317) で操作がキャンセルされました。 .reflect.NativeMethodAccessorImpl.invoke0 (ネイティブ メソッド) (sun.reflect.NativeMethodAccessorImpl.invoke (不明なソース))、sun.reflect.DelegatingMethodAccessorImpl.invoke (不明なソース)、java.lang.reflect.Method.invoke (不明なソース)、org .kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:160) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:76) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java: 73) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30) で org.kohsuke.stapler.Stapler.invoke(Stapler.java:436) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:186) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30) at org.kohsuke.stapler.Stapler.invoke(Stapler. java:436) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:354) at org.kohsuke.stapler.Stapler.service(Stapler.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet) .java:45) で winstone.ServletConfiguration.execute(ServletConfiguration.java:249) で winstone.RequestDispatcher.forward(RequestDispatcher.java:335) で winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378) で hudson.util.PluginServletFilter hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:83) で $1.doFilter(PluginServletFilter.java:91)195) winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) で hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) で hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) で hudson.security .HudsonFilter.doFilter(HudsonFilter.java:155) で winstone.FilterConfiguration.execute(FilterConfiguration.java:195) で winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) で winstone.RequestDispatcher.forward(RequestDispatcher.java:333) でwinstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) で winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) で java.lang.Thread.run(不明なソース)doFilter(ChainedServletFilter.java:84) で hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) で hudson.security.HudsonFilter.doFilter(HudsonFilter.java:155) で winstone.FilterConfiguration.execute(FilterConfiguration.java:195) ) winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) で winstone.RequestDispatcher.forward(RequestDispatcher.java:333) で winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) で winstone.RequestHandlerThread.run(RequestHandlerThread.java) :150) java.lang.Thread.run で (不明なソース)doFilter(ChainedServletFilter.java:84) で hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) で hudson.security.HudsonFilter.doFilter(HudsonFilter.java:155) で winstone.FilterConfiguration.execute(FilterConfiguration.java:195) ) winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368) で winstone.RequestDispatcher.forward(RequestDispatcher.java:333) で winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) で winstone.RequestHandlerThread.run(RequestHandlerThread.java) :150) java.lang.Thread.run で (不明なソース)RequestDispatcher.doFilter(RequestDispatcher.java:368) で winstone.RequestDispatcher.forward(RequestDispatcher.java:333) で winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) で winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) でjava.lang.Thread.run(不明なソース)RequestDispatcher.doFilter(RequestDispatcher.java:368) で winstone.RequestDispatcher.forward(RequestDispatcher.java:333) で winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) で winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) でjava.lang.Thread.run(不明なソース)

継続的インテグレーションサーバーにHudsonを使用していますが、これはすばらしいことです。これには2つの問題がありますが、これらは穏やかに関連しています。

1. https://hudson.dev.java.net/issues/show_bug.cgi?id=2736 Hudsonのビルド順序は、ダウンストリームの依存関係が必要以上にビルドされることを意味します。うまくいけば、この問題はすぐに解決されるでしょう。
2. これらのものは頻繁にビルドされるため、ビルドの履歴は膨大です。一部のジョブでは、履歴に1000個のビルドアイテムは必要ありません。

私の質問はポイント2についてです。古いアーティファクトを削除するジョブやプラグインのようなものが欲しいです。周りのすべての最後の20ビルドは問題ないだろうと言い続けます。現時点では、制限がないように見えますが、運用の観点からはあまり良くありません。

更新：Norbertの回答によると、それはジョブ構成にあります。1.300 UIには、「古いビルドを破棄」チェックボックスがあり、これを構成できます。