問題タブ [build-automation]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
api - CruiseContol.NET Web ダッシュボード レポートの XML バージョンに (HTTP 経由で) アクセスする方法は?
最後のビルドの状態 (成功/失敗) を判断する必要があり、次のようにします。
しかし、これは無駄が多く (HTML ページ全体をロードする)、エラーが発生しやすく (既にバイト/ユニコードのバグに遭遇しました)、脆弱です。
build-process - Visual Build Professional で反復的なユーザー定義アクションを作成する方法は?
VBP では、カスタム COM コンポーネントまたはカスタム スクリプトを作成することで、ユーザー定義のアクションを定義できます。
iterativeであるユーザー定義のアクションを作成する必要があります。つまり、アクションに組み込まれた「プロセスファイル」のように、子ステップを反復的に呼び出す必要があります。
これを行う方法がわかりませんし、Google も役に立ちません。
svn - NAnt を使用して SVN 追加を自動化する
NAnt を使用して SVN の追加を自動化したい。特定のディレクトリにあるすべての新しいファイルを SVN に追加したいと考えています。NAnt スクリプトは add コマンドを正常に実行しますが、Tortoise SVN 追加ダイアログが表示されます。これは、CruiseControl を実行しているビルド サーバーで実行されるため、受け入れられません。ビルド サーバーは Windows Server 2003 を実行しています。
何か案は?
java - Maven 2 でデフォルトで実行されないように、長期実行 (ストレス テストなど) を分離する方法はありますか?
ストック Maven 2 ツールとドキュメントを使用して対処する方法がわからないというニーズが常にあります。
一部の開発者は、非常に長時間実行される JUnit テスト (通常はストレス テスト) を行っており、どのような状況でも、ビルド プロセス / ナイトリー ビルドの通常の部分として実行する必要はありません。
もちろん、surefire プラグインの除外メカニズムを使用してビルドからそれらをパントすることもできますが、理想的には、開発者が Maven 2 を介して自由にそれらを実行できるようにしたいと考えています。
delphi - アプリケーションを見つけて反復する Ant ビルド
Ant を使用して Delphi アプリケーションを構築します (CruiseControl から呼び出されます)。
ファイル *.dpr を探してディレクトリツリーを再帰的に検索し、見つかったときに2番目のbuild.xml、またはできればマクロまたはターゲットを呼び出して、見つかった各ファイル名を「パラメーター」として渡します。subant を使用して build.xml ファイルを見つけて順番に実行できることがわかりましたが、アプリケーションごとに build.xml を作成する必要がないようにしたいので、これは私が望むものではありません。
私が回避しようとしているのは、build.xml でアプリケーションを箇条書きにしなければならないことですが、むしろそれらを見つける必要があります。
私たちはすでに Ant の使用に多額の投資を行っているため、別のビルド ツールを使用するように言わないでください。
javascript - jsUnit-ant-script の相対パスを指定するには?
JsUnitは、「standalone_test」をターゲットとする ant-script を提供します。このターゲットは、プロパティ url を使用して、テストを実行する HTML サイトを識別します。これらのサイトはチェックインされているため、チェックアウト後に誰もがこのテストを実行できるはずです。これは機能しますが、url-proprty は のような絶対パスに設定する必要がありますfile:///home/user/projects/my-project/path/in/project/jsunit/testRunner.html
。これにより、自動開始が回避されます。誰もが自分のボックスで構築されたパスを使用してコマンドを指定する必要があります。これらのテストの実行を自動化できるように、代わりに相対パス/URL を渡すことは可能ですか? これは、継続的インテグレーション システムでこれらのテストをセットアップするのに役立ちます。
build-automation - クルーズコントロール ソースセーフ ブロック
作業中のビルド マシンには多くのプロジェクトがありますが、問題が発生しているのは 1 つだけです。
2 つのプロジェクトは非常に似ており、1 つはデバッグ モードでビルドされ、もう 1 つはリリース モードでビルドされます。どちらもプロジェクト ディレクトリをクリアしてから、ソース セーフから完全な Get を実行します。デバッグ ビルドはソースを問題なくかなり迅速に取得しますが、リリース ビルドはソースを取得するのに時間がかかります (CheckingModifications 部分で長時間一時停止しますが、デバッグ ビルドはそれほど長く一時停止しません)。ソース管理ブロックは同一 (1 つのファイルからインクルード) であり、次のとおりです。
リリースビルドのソース管理ブロックが遅い理由について何か考えがある人はいますか?
python - Python から VS2008 ビルドを起動する
これを手動でコマンド プロンプトに貼り付けると動作しますが、Python から実行するとThe filename, directgory name, or volume label syntax is incorrect
.
python - Pythonからvs2008ビルドを起動する
最初のバッチファイルはコマンドプロンプトを起動します。2番目のコマンドを最初のコマンドのccontextに含める必要があります。Pythonでこれを行うにはどうすればよいですか?
そのまま、バッチを起動し、バッチ(コマンドプロンプトコンテキストを含む)が終了するまでブロックしdevenv
、必要なコンテキストなしで実行します。
私はbashにいるのと同じように考え、perlコンテキストでコマンドを実行する必要があるので、と入力しperl -c 'asdf'
ます。perlとasdfを連続して実行しても機能しません。perldevenv
コンテキストの内部を取得する必要があります。
build-automation - nmake を使用して C++ プロジェクトのプロジェクト ツリーを整理する方法は?
プロジェクト ファイルの編成には 2 つの主要な規則があり、その後に多くのバリエーションがあるようです。
規則 1: 高レベル タイプのディレクトリ、プロジェクトのサブディレクトリ
たとえば、wxWidgetsプロジェクトは次のスタイルを使用します。
長所:
- プロジェクトの依存関係がある場合は、単一のファイルから管理できます
- フラットビルドファイル構造
短所:
- test には独自のヘッダー ファイルと cpp ファイルがあるため、ライブラリではなく EXE ファイルの単体テスト アプリケーションを生成する場合、テストするアプリケーションのオブジェクト ファイルを含める必要があります。これには、推論規則を作成し、すべてのソース ファイルの相対パスを展開する必要があります。
- 別のソリューションでプロジェクトを再利用するには、ツリー構造から適切なファイルを抽出し、ビルド スクリプトを変更する必要があります。
規則 2: 高レベルのプロジェクト ディレクトリ、タイプ サブディレクトリ
たとえば、Wiresharkプロジェクトはこのスタイルを使用します
長所:
- プロジェクト自体はフォルダー内に自己完結型であるため、移動や再利用が容易になります
- ビルド ツールでより短い推論規則を使用できるようにします
- 階層的なビルド スクリプトを容易にします
短所:
- プロジェクト間に依存関係がある場合は、ビルド順序を管理するために、プロジェクト ディレクトリの上にビルド スクリプトのレイヤーを追加する必要があります。
現在、プロジェクトで規約 1 を使用していますが、これまでのところかなりうまく機能しています。現在、私は単体テストを (CxxTest を介して) 追加し、nmakeを使用して継続的インテグレーションへの移行を促進しています。規則 1 は、適切な nmake ファイルの作成に深刻な頭痛の種を引き起こしています。
私の主な要件/目標は次のとおりです。
ソリューション全体のビルド スクリプトを維持する労力のレベルを減らします。
ソリューション内のプロジェクトとそのビルド手順を他のプロジェクトから切り離します。
チェックアウト用のビルド スクリプトを使用して、コミットごとにメディア生成をリリースすることで、継続的な統合を促進します (もちろん、CruiseControl などの他のツールも活用します)。
追加のプロジェクトまたはソース ファイルの追加または削除を、開発者にとって可能な限り簡単にし、エラーの発生を最小限に抑えます。
だから私は尋ねます:
- これらの方法のいずれかの他の長所と短所はありますか?
- これらの慣習の 1 つだけを支持する明確な反対意見はありますか?