2

現在、jenkinsを使用して、意図したリリース条件下でアプリケーションをデプロイしています。デプロイされたシステムでrootユーザーとしてJUnitテストを実行する必要があります（アプリケーションには、rootのみがアクセスできる特定のファイルがあるため）。

「invokeant」ビルドステップを使用してテストを実行する代わりに、「executeshell」ビルドステップのsudoを使用してantを実行しています。

sudo ant -file build.xml -D.... test

jenkinsユーザーはこれを行うために必要なroot権限を持っていますが、上記のファイルにアクセスすることはできません。

これを行うと、ワークスペースに間違ったアクセス許可を持ついくつかのフォルダーが作成されることに気付きましたが、「シェルの実行」の後でこれを修正します。

すべてがうまくいったように見えますが、それは少し回避策のように感じます。

それでは、私の質問は、ビルドステップ「antを呼び出す」と比較して、この方法でantを実行することの不利な点はありますか？...または誰かがこれを行うためのより良い方法を見ることができますか？

4

4 に答える 4

1

Jenkinsはシェルコマンドで「invokeant」を翻訳します。ビルドのコンソール出力を見てこれを確認できます。したがって、問題を解決した場合は、同じだと思います。

于 2012-05-21T19:39:47.463 に答える
1

ANT ビルド ステップの背後にある主なアイデアは、プラットフォーム間で統一性を提供することです。したがって、「構成地獄」を回避するために、可能な限りそれを使用する必要があります-さまざまな構成の組み合わせの爆発。しかし、時には、男性は男性がしなければならないことをしなければなりません.

于 2012-05-21T20:37:49.677 に答える
1

あなたの制約を考えると、あなたのソリューションは問題ないと思います。

あなたの質問に答えるには：

...is there any disadvantage of running ant in this manner...?

頭に浮かぶ主な問題は、Windows を実行しているスレーブと UNIX を実行しているスレーブがある分散 Jenkins デプロイメントがある場合、これは明らかに機能しません (または、少なくともより多くの作業が必要になります。たとえば、Cygwin のインストール/構成など)。 ）。しかし、それはあなたが本当に気にかけていることではないと思います。

おそらくよりクリーンな代替ソリューションは、ルートとして実行される単一の Jenkins スレーブをセットアップし (必要に応じて Windows では「管理者」)、ジョブをそれに結び付けて、Ant 呼び出しに対して「Ant を呼び出す」ことに固執することです。しかし、それをセットアップするにはかなり多くの作業が必要であり、おそらくその労力に値するものではありません。

于 2012-05-21T20:41:37.917 に答える
0

すべてが正常に機能する場合、シェルから ant を使用しても問題はないようです。あなたが言及したように、変更されたファイルのアクセス許可は、実行後に問題になる可能性があります。

于 2012-05-21T19:51:11.683 に答える