thanks we managed to find it as nuget was packing the release and debug files over the top of each other for some stupid reason in just the packages generated for this project. no idea why it did not affect any other solution on our build server

Great questions. a second Raft, that uses the same Git repo but a different branch? This was definitely something we considered when designing rafts... i.e. the ability to "promote" changes between environments. This is somewhat common in other IaC tools, such as Chef, where a cookbook is tied to a git repository. Some folks will use branches in this "promotion" manner. I was also thinking of having a second Otter Server instance for the pre-production environment This is fine; actually, our licensing model is designed for this. One instance of Otter managing pre-production servers (typically free), then the other instance managing production servers. Obviously you loose the unified visualization, but a lot of folks prefer having two totally different dashboards anyway. A lot of folks will also set up a second instance of Otter as more of a "Sandbox". It isn't to "test" the configuration plans, but more to test extensions, play around, try upgrades, etc. hope that helps.

Retention policies are available on paid versions of ProGet, so "ProGet Basic" and up; you can see current ProGet Pricing here.

Well... the error is a bit strange, because EnumerateFileSystemInfos is in fact a method on System.IO.DirectoryInfo. It's a core .NET class, so this error is "impossible" then... I'm wondering if there's an older version of powershell or .net on the server? There has to be some other difference between the servers I would think... You can trigger the RoutineServerChecker under Admin > Service. Hopefully you'll find some clues by running it repeatedly...

There is no way to configure that in the schedule, but you can somewhat accomplish this by either: setting the filter to "newest active release" and moving the release to the top on the Release Sequence page or, if you don't mind multiple failed builds in your release, setting the filter to "all releases" and filtering at the top of the build plan, e.g. if $CompareReleaseSequence(!=, $ReleaseNumber, $DesiredReleaseNumber) { Log-Information `$ReleaseNumber is $ReleaseNumber, skipping.; fail; }

Alana, I think it maybe a UTC boom... I will try today to "fiddler" it.

I see. Is it possible to leave a reminder of that limit on UI somehow? Like how many characters left that kind?

It is working :) Thank you Have a nice week-end Regards Philippe

Thank you for the report. This will be resolved in the next maintenance release as issue OTTER-130.

Thank you for this amazing honest answer, Coming from .NET and Nuget, i've been enjoying the struggles of npm and it's evil offspring for a while now, haha All developers swear it's so good, until we need to make builds from their code...

I found the solution. I had tried several different ways but finally found the right way. Just putting folder/job/jobname in the List Source made it work. The list won't auto show the job but you can type it in and it works.

Yes of course, smacking forehead now! Thanks!

Spectacular - that was exactly what I was hoping. Thank you for taking the time to answer!

There is a "multi-domain / forest" AD provider. As long as the domains have a trust to eachother, then the users from the other domain will be enumerated and it should "just work". We are considering building a new active directory provider that allows you to explicitly list the domains to query (instead of doing a trust search), but that ended up getting really complex fast, so it's on hold just for a bit...

Yes, that's precisely what it would be; an ATOM feed for private galleries that you can push extensions to. I think only MyGet supports it now, so we will look to them for how they handle pushing, so it can be consistent. Most of our enterprise customers wanted to create a workflow like they do with NuGet.org, with only certan public packages in the feed, etc. THat is, they didn't have custom extensions, they only wanted to restrict or cache public extensions for their developers.

Just to clarify... the "NuGet v3 API" is intended for internal-use (i.e. only nuget.exe and NuGet VS extension). Microsoft's new position is that they do not intend on making this API public or stable in the foreseeable future, and that they will continue to support the "NuGet v2 API" (which is documented and public) indefinitely. They actually use ProGet to test changes to v2 API. That said, until this position changes, we will not reverse-engineer the v3 protocol. So this means you will need to use nuget.org/api/v2 in your connector, not the v3 url. Both v2 and v3 API work with client tools, both support DotNetCore, etc. If you're finding a issues with DNC projects, then it's likely related to framework monikers or something like that. Please submit a ticket for this with specifics, so we can investigate and patch.

Unfortunately Visual Studio doesn't support authenticated symbol servers; i.e. if ProGet sends a 401 response, there is no authentication challenge. We may be adding a feature in 4.7 that allows for "url authentication" of sorts, where you use a "obscured" url with an api key in it somewhere that will cause authentication to be effectively bypassed.

It's hard to say, so we'll need to diagnose a bit further. Could you submit a ticket for this, with the following: which packages work? something from a package that doesn't work... package type (NuGet, npm, etc) metadata file (like nuspec, package.json, or entire package is fine) screenshot exhibiting this behavior With this, we can go back-and-forth over email a bit easier.

Auth tokens are now supported for npm feeds; you'll need to create the token as a ProGet API Key. Please see the API & Access Key documentation to learn more. This is an updated answer; earlier the answer mentioned the feature was not supported.

Pb solved with the 1.5.2