Hi Anup, Here is some documentation regarding active directory configuration across all of the Inedo tools: Using LDAP & Active Directory

Hi Bret, A tutorial for TeamCity is here: https://inedo.com/support/tutorials/buildmaster/teamcity/choosing-specific-artifact-from-teamcity Future note, the TeamCity tutorial may be moved to https://github.com/inedo/inedox-teamcity/wiki as part of a docs re-organization. As for controlling Apache, this is done through the httpd command, which can be executed with an Exec operation in your deployment plans, e.g.: # Deploy to Apache { Exec httpd -k stop; # deploy artifacts... Exec httpd -k start; }

Hi Anderson , Of course, a lot of our customers host ProGet in the cloud, and just install it on their own server in the cloud. But, we found it wasn't so popular to pay us to do that. The pricing was basically hosting costs + license costs + overhead, so something like $150/mo, depending. We stopped offering it, because we found most customers were either looking for a cheap, multi-tenant service (like $20 to $50/mo), or for really advanced infrastructure far beyond our capabilities (like dozens of servers globally linked, at like $10k/mo+). We are planning to launch “bring your own license” VM/Container in the cloud services at some point, and may leverage that as a hosted option. Any datapoints or insights you might have are always welcome, and I’ll share those to our leadership!

I did try that and it works outside Docker where it just uses the user that is running it. Within Docker though I can't get it to work. I tried giving it creds or api key and it just won't validate. On proget it never shows an attempt when it's the api key either. Anyway, this work around is working so now i'm progressing. I'll pass on the details once I have it working. Thanks.

Hi Alex , Thank you for your feedback . I understand better now . Of Course , I will share with you and the community , the way I'm doing when they are correctly setup , tested and approved . Best Regards , Andry

ProGet is licensed per server, so you need a separate license per server. We do permit temporary using the same key in the case of moving servers, etc., but only if they're used in a temporary state and decommissioned soon.

Eventually, but we haven't had too many requests for it :) If this is something you're interested in, we'd love to partner with a customer or two to help get this developed.

Hi Dean - apologies, other priorities came up and I lost track of this. I see your point regarding those extensions. I would be interested in getting our custom extension running if possible, so yes if you can contact me directly that would be great

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.