I actually added this but it wasn't released as part of the beta; it will be an option in the Status filter e.g. "Agent error", "Collect/remediate error", and "Any error"

Hello Mickael, ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address. Here's the documentation for setting up SSL Traefik and nginx: https://docs.traefik.io/user-guide/examples/#http-https-with-sni https://nginx.org/en/docs/http/configuring_https_servers.html

Hi, How would you like the error code handled? Would you like the option to store it in a variable, be used to determine success, or just logged somewhere? I believe we can add this by updating the Linux extension. As a workaround, you may be able to use the Exec operation, which already has exit code handling.

Are you granting "Anonymous" the permission to view/download packages? If you remove that from the User Tasks page, then authentication would be required.

Alright, I have my one token agent I had to update. Thanks!

I haven't been able to reproduce this. What is the exact request you are making to the API that isn't working?

Hi Alana, Thanks for the information. I've reinstalled ProGet and IIS several times and at attempt four it suddenly worked fine. So I'm not touching the setup anymore and will keep it as-is now! Thanks, Eelko

A GitHub repository contains only code, so you will want to treat it as if it were a package you wrote yourself. This means download the source code, compile it, package it per the appropriate packaging method (e.g. npm, NuGet, etc), then upload that package to ProGet. You can use something like BuildMaster to automate this workflow.

Please check the Symbol and Source Server; basically you will want to use a symbols feed. The /symbols endpoint is not a Nuget feed, so you can't push packages to it.

Good catch, that's a bug on the auto-generated versions page. Here is a better statement, which we've had for a while on our BuildMaster Roadmap Page: v4 is semi-retired, which means that we will provide very limited support to v4 users who have not yet upgraded, and will provide assistance in performing upgrades. However, we will no longer ship maintenance releases, patches, or other changes. I emboldened the key part; we're here to help, so please schedule some time with our engineers to help you upgrade. And for reference, please see KB#1151: Upgrading from BuildMaster v3 and v4

In order to prevent inclusion of prohibited licences, you will need to have all dependencies pulled through ProGet feeds to prevent them being downloaded in the first place. This also serves as a quality gateway, to ensure low-quality packages/components aren't introduced into your projects. You can enforce this at the build server (for example, with BuildMaster): simply have your build server always use ProGet as the only dependencies source, and this way if developers try to bypass ProGet, it simply won't build.

Licenses are activated against a particular machine, but they are not attached to that machine. If you transfer the license in the manner you describe (install on new server, uninstall on old server), then it's in compliance.

I'm afraid you are simply producing invalid packages. Per the NuGet specification, a package id "may not contain spaces or characters that are not valid for a URL" ProGet could validate better on upload, but ultimately you need to stop producing invalid packages if you want to use them in TFS, VS, etc. Even if ProGet supported invalid packages, it's highly likely that those tools won't, and will stop working all of a sudden.

Thanks very much, Scott. You helped me by mentioning that the feeds themselves also need to support SemVer 2.0. I wasn't aware of that fact. So I just migrated our feeds an now everything works fine.

Yes, we're currently using dotnet nuget push to push packages. We're using the "legacy" *.symbols.nupkg format, though, to be safe.

This is also being discussed here; long story short, this is a bug in Microsoft's PowerShell Gallery (and in the packages) in that they have two conflicting version numbers, and sometimes one is used, sometimes the other is used. The docs have been updated for now: https://github.com/Inedo/inedo-docs/commit/10c42c3ad546ac2feb4748b7736db06567c7a6d6

Okay, I've resolved it. The problem was that I'd put in the project name without a path - so BuildMaster was assuming a default path. The message was really unclear. It would be beneficial to allow the user to populate that field with a 'browse' function to find the solution/project or, at the very least, have some validation on the input to ensure you've entered something which looks like a full file path.

That error is coming from the SSH library that BuildMaster uses to connect, and offhand I don't know the causes (aside from obvious). One possibility is that username/password isn't enough, and you need to send a certificate. Putty may already be configured to do this. But can you enable SSH logging on your Linux box? This way, you can see the problems of incoming connections and we can further help from there.

Hi Ryan, Sorry for the delay in getting back to you - we're planning to add this to ProGet 5.2, which currently has a release date of April 11. It should be included in Inedo SDK 1.1.2 (see tentantive spec here). Does that look like it will cover your situation?

I would try reinstalling it. I didn't have to create the site in IIS.