We definitely want to add these as first-class Operations in our Windows extensions, but in the mean time the best route is to use the PSDsc Operation to invoke the Windows Feature DSC Resource

PSDSC WindowsFeature
(
  Name: Web-Server,
  Ensure: present
);

Hope that helps!

Will help support a push command at some point? ;-)

We documented a few ways you can Publish Helm Charts, because there was no push command at the time. It doesn't seem there's now one... https://helm.sh/docs/helm/

Can you be more specific? I don't understand?

You most definitely do not want to "throw away" your package store or database...

There shouldn't be a problem doing this. Just makes sure the BaseUrl is configured properly in Advanced/All Settings under Admin.

FYI: it's on our roadmap to have BuildMaster (and Otter) work on a multi-node installation, so you could have multiple web and multiple service nodes (similar to ProGet).

This is why it works directly...

Remember that the NuGet.org not only runs on a massive web farm with dozens of load-balanced servers, but it's a static-file based index that's done mostly with CDN-based files.

Each request you make to ProGet, on the other hand, needs to be authenticated, checked for vulnerabilities, licenses, sent to connectors, etc.

The sockets are not getting exhausted, the async awaits are timing out. This is exactly what to expect in a connection overload situation, which will be common place in the way you're using ProGet.

ProGet is not designed nor supported as a desktop tool.

That's strange, but it sounds like request filtering, WebDav, or some other security feature (outside of ProGet)... ProGet doesn't restrict anything by extension or anything like that.

There's a few places to look, but i'd start here:

https://stackoverflow.com/questions/12828476/what-file-extensions-are-blocked-by-default-in-iis

Is that helpful?

Oh; yeah that'll definitely do it.

50 packages yields hundreds of requests to a NuGet feed (ProGet). Each request to ProGet is then forwarded to Nuget.org. Add to that Docker request routing, PostGres network connections... and all of this on a single machine, calling itself over network channels...

You're basically DoS-ing yourself ;)

Hi; do you have any specific recommendations? We are reevaluating our Docker strategy, perhaps to include things like Swarm or Kubernetes as distribution options.

Here's what we do now...

https://github.com/inedo/proget-docker

I'm just following up to see if you were ever able to work-past this, or if it's still an issue?

This is on our future roadmap; for now you'll need to install and manage as a normal windows application.

@philwaller5269_6322 what page did you find the broken link on?

There was a regression for the PowerShell agents that caused this to behave like this in some cases, but it was fixed in Otter 2.2.5 (released today). I should be fixed

Let me know if this resolves your issue!

The first example you mentioned (i.e. the one to /api/management/feeds/create) is using the Feeds Management API; it looks ok to me on first glance... can you share the error message you got when invoking it? You should be able to see logged request/responses in the Admin > API Keys as well.

The second example you mentioned (Feeds_CreateFeed) is using the Native API, which we don't really recommend if there's an alternative available. It is basically a wrapper around stored procedures and the database. But in this case, it looks mostly correct, but the FeedType_Name is wrong; if you look at the Feeds table in the database, you'll see a universal feed is actually called ProGet in the database.

Anyways, please use /api/management/feeds because it's easier to use and won't change if we update the database or stored procs.

Quick update: there's a bug we identified with some WsMAn connections that are causing different errors, but it might be related. We're going to fix this in Otter 2.2.5, shipping Friday.

Otter 2.2.2 doesn't seem to exhibit this behavior.

Long story short, your workstation is overwhelming your server with network connections.

Remember that the NuGet.org not only runs on a massive web farm with dozens of load-balanced servers, but it's a static-file based index that's done mostly with CDN-based files.

Each request you make to ProGet, on the other hand, needs to be authenticated, checked for vulnerabilities, licenses, sent to connectors, etc. And I would be surprised if your server is more powerful than your workstation.

There are some features in ProGet Basic like metadata caching that will help, but ultimately when you scale to more developers you ought to invest in better server hardware and eventually load balancing. See https://blog.inedo.com/proget-free-to-proget-enterprise

This is because Get-Http is an execute-only operation, which means it will only run if configuration changed.

To force execute-only operations to run in configuration plans, you need to specify the execution directive to be always execute, as follows...

with executionPolicy=always 
{
   ...
}

Hopefully we can better document this in the future; it's buried in the formal specification.

@knitvijay_7631 said in During build getting error (unable to clone from github):

Clone failed: unknown certificate check failure

I did a quick search on this message, and there's lots of advice on how to get this working. The problem is coming from Git, and BuildMaster is just reporting the problem. I think your best bet will just be to use HTTPS instead of SSH. It's a lot easier to configure...

BUt here's a post that seems to be quite popular that gives lots of tips and tricks on resolving this..

Example: https://stackoverflow.com/questions/3777075/ssl-certificate-rejected-trying-to-access-github-over-https-behind-firewall

That's not surprising; as I mentioned, the problem lies with your configuration. Either you're using the wrong name and password in Otter, or the WSMan endpoint on the remote server isn't enabled.

I recommend you to use to Inedo Agent.

We hope to include this ability in a future release, but it's a bit more complicated to get the details worked out. For now, just uninstall, then reinstall (pick version you want) will work.

Here is the underlying error message:

Can not connect to Windows servers with WSMan endpoint. Try to use credentials FQDN and Netbios, result - exception.

Basically, this means that your username/password is not being accepted. It should be something like DOMAIN\username or username@domain.local

It could also be that WSMan isn't configured to allow these connections; this can be controlled at the domain. I recommend you use the Inedo agent, it's a lot easier to set-up and get working