問題タブ [proget]

CI ビルドの依存関係とその依存関係に ProGet の使用を開始したいと考えていますが、これにより多くの NuGet パッケージがフィードに残る可能性があり、唯一のオプションは一度に 1 つまたはフィード全体を削除することです。

最後の 10 個を除くすべてを削除し、さらにフィードに NuGet パッケージ保持ポリシーを実装する別の方法はありますか?

どうもありがとう

内部の ProGet サーバーを介してインストールされたシュリンクラップ パッケージを使用すると、ECONNRESET の問題が発生します。npm レジストリを通常の npm レジストリに構成し、それに基づいてパッケージをシュリンクラップすると、すべて正常にインストールされます。node_modulesを削除し、実行の合間にnpm cache cleanを実行して、ProGet からのダウンロードを強制します。興味深いことに、 npm-shrinkwrap.jsonにリストされている 1,000 以上のリソース リクエストはすべて、ファイル ダウンローダーに接続すると正しくダウンロードされます。

詳細フラグを指定してインストールすると、npm クライアントがレジストリ URL をhttp://<internal-url>/npm/npmから任意に変更して、一部の要求でnpm /npmを省略するように見える多数の 404 が表示されますが、なぜそれが起こるのか、それが関係しているかどうかはわかりません。

ProGet 3.8.6、npm 3.3.11 および 3.5.4 (2 台の開発者マシンでテストしても同じ結果)、およびノー​​ド 4.2.1 を使用します。

私はこのコマンドを実行しました

私は何かを得ています

しかし、ブラウザからサーバーにアクセスできます。どこで間違ったのか、どのようにパッケージ nuget サーバーをプッシュするのか

私は、開発者として通常の開発プロセス内で継続的インテグレーションを使用することにかなり慣れていません。しかし、私は ci を私たちのソフトウェア チームに導入する仕事をしてきたので、これを達成するためにいくつかの試みを行ってきました。

現在、次のものがあります: 0. ソース リポジトリとしての BitBucket 1. Team City 2. ProGet サーバー 3. Octopus Deploy 4. 開発テスト VM 5. UAT テスト VM 6. 本番 VM

一般に、プロセスは次のようになります

1. リスト項目
2. BitBucket からソリューションを確認する
3. 変更を加える。
4. Bitbucket にコミットする
5. チーム シティ ビルド
6. Team City は成果物を nuget パッケージとして ProGet にプッシュします
7. Team City は Octopus Deploy でリリースを作成し、Development Test vm への自動デプロイをトリガーします。
8. UAT への手動 Octopus プッシュ
9. Octopus による本番環境への手動プッシュ

私たち開発者を除くすべての人にとって、トップレベルのすべてが問題ないように見えます。

私たちの問題はコンセプトではなく、プロセスと共に生きることです。その理由は、2 番目のソリューションが ProGet サーバーからの最初のソリューションのナゲット パッケージを参照する 2 つのソリューションがあるためです。これが意味することは、依存ソリューションが最初のソリューションで変更を必要とするたびに、サイクルが発生するのを待ってから、2 番目のソリューションで nuget パッケージを更新して必要な変更を完了する必要があるということです。

必要な結果が得られるまでにこのサイクルが何度も発生する必要がある場合、これは非常にイライラします。

私が望むのは、ci が変更されたパッケージをビルドして公開するのを待たずに、開発者の PC で両方のソリューションを開発することです。これは、最初のソリューションの dll がローカルで参照されることを意味すると思いますが、これを変更して、最終的な参照が ProGet サーバーから CI ボックス上に構築されるようにするにはどうすればよいですか?

誰でもこれを行う方法を教えてもらえますか?

私は 2 つの Windows マシンを持っています。1 つはNexus OSS 3を実行し、もう 1 つはProGetを実行してい ます。

ProGetにあるフィード/リポジトリの 1 つを指すnuget プロキシ リポジトリを Nexusに作成したいと思います。私はこのガイドに従っています: nuget プロキシ リポジトリでは、Nexus OSS 3 をインストールするときにデフォルトで付属するnuget.org-proxyプロキシ構成を基本的にコピーしました。

しかし、コマンドラインからこのエラーが発生し続けます

そしてNexusのウェブログ:

プロキシ リポジトリの URL をソースとして指定して、パッケージXで nuget install を実行すると、次のようになります。

そのパッケージは確かに元の ProGet フィードに存在し、代わりに直接/非プロキシ フィードを指定すると、インストールは正常に機能します。

nuget バージョン 2.8 および 3.4 で試しました。

私の ProGet サーバーはビルトイン認証で構成されています。

匿名にはダウンロード アクセス権があります。

Anonymous が ProGet サーバーでダウンロード アクセス権を持っているのに、なぜこのアクセス エラーが発生するのですか?

maven パッケージを proget サーバーにデプロイしようとしています。ただし、一時停止後に mvn deploy を実行すると、エラーが発生します。

Firefox を使用して URL に接続できますが、curl はできません。ただし、curl --insecureオプションを使用すればできます。何が間違っているのでしょうか？

このコマンドラインを試しましたが、まだ同じ問題が発生しています。

私はプロキシを使用していますが、http_proxy および https_proxy 環境変数が設定されており、他のアプリケーションでも機能するようです。Mavenはこれらに注意しますか？

私はこれに対する解決策を広範囲に探しましたが、見つけることができません。

シンボルとソースの両方を含むパッケージを ProGet に公開するように TeamCity を構成しました。このプロセスはうまく機能し、ProGet はシンボルを正しく識別します。

ProGet のナレッジ ベースの指示に従って Visual Studio をセットアップしました。

• options->Debugging->Symbols にシンボルの場所を追加する
• 有効化されたソース サーバー サポート オプション -> デバッグ -> 一般

Fiddler をチェックインしました。アプリをデバッグで起動すると、シンボルがダウンロードされます。

次に、パッケージ内のメソッドの 1 つにステップ インすると、間違ったファイルが開かれます。ただし、開くファイルの名前は同じです (各パッケージと、パッケージをプルするローカル ソリューションに Component というファイルがあります)。

ファイルの名前を変更して再パッケージ化して ProGet に公開すると、問題はなくなり、デバッグ中にファイルにステップインできますが、これはハックのようです。

ソリューション内の同じ名前のローカル ファイルよりもシンボル サーバー上のファイルを優先するように Visual Studio を取得する方法を知っている人はいますか?