Somewhat similar to the post you've read already, but I've provided an answer to this kind of problem before: https://inedo.com/support/questions/7990 Basically it's setting up two IIS sites, one with Windows auth the other with Basic Auth (or anonymous if you want). One instance of ProGet, but two ways to get to it. We've been successfully using ProGet with both Windows Auth (for .NET nugets) and Basic Auth (for npm and docker) for about a year now, with the configuration described in the post I referenced. David

Hello Subash, To check whether any connectors are unhealthy, you could use a PowerShell script like this: $someConnectorsUnhealthy = ( Invoke-RestMethod 'https://devget.syhapp.com:8798/api/json/Connectors_GetConnectors?API_Key=*******&Feed_Id=***' | Where-Object { $_.Status_Code -ne 'H' }).Count -gt 0 After this, $someConnectorsUnhealthy is $True if any connectors for that feed are not in a healthy state, and $False if all connectors are healthy. If your API key contains = or +, it needs to be URL-encoded, with = replaced by %3D and + replaced by %2B. Alternatively, you can change the API key to be URL-safe.

Thank you for the followup, that is good information. For future reference, the docs for switching from the built-in webserver to IIS can be found here: https://inedo.com/support/kb/1013/hosting-through-iis-instead-of-the-integrated-web-server The only thing I notice from the article is the mention of Classic mode for the application pool - at some point each product was updated to support Integrated mode.

That's actually pretty awesome. that's exactly what I was sort of thinking of doing.

I second this. Need to learn Markdown, though

Thank you with version 4.8.12, it's working.

Yes, here is the tracking issue: BM-3165

INdeed; actually, we've updated our documentation on this matter -- and we do have supporting the v3 api on our roadmap now that it's supported by Microsoft.

This is not supported at this time.

Hello Dmytro, I've filed PG-1252 to address this.

Hi Ben, Yeah adding a licence fixed this problem. Thanks for the hint. Have a nice day.

Hi Ben. Thank you for the clarification of the problem scope. Look forward to the fix. Thank you for the quick response, much appreciated +1 Inedo has excellent support and reacts promptly.

Ben, I didn't set it for any particular stage. Based on what you're saying though I think the issue was that didn't have the Listener in place when the app had completed the previous stage. I assumed the email would only go out when the Stage the approval was attached to was initiated for deployment but it sounds like it would do so when the previous stage completes, is that correct?

Unfortunately this is a bit tricky to give "general" advice on how to fix, but if you can submit a specific test case that we can reproduce as a ticket, we can research and try to reproduce it,.

The "remote icon" means that there is a package entry in a remote server. If you're continuing to see it, then it may take a little bit for the connector metadata (in memory)cache to be cleared. You could always stop/start the webservice, and then this will go away.

To be honest, "SCM Triggers" are in a "quasi-legacy" state, because they use the "Legacy Providers". As such, we don't list it as a feature, and we hide the button on installations without SCM Providers configured. This was done slowly over the course of two years, in various v5 versions, to gauge user reaction. So, your inquiry is good feedback. That being said, we have not yet put a lot of effort into properly redesigning this feature. The reason for this, is that the "general direction" has been moving towards post-commit hooks; i.e. triggering the build from the SCM server, once a merge request (or something?) happens. Even on dedicated CI tools, the preference is shifting towards this route. I think this is because the branching logic has been too complicated to follow (even for really advanced CI servers like Jenkins and TC). So I wonder, have you looked into post-commit hooks? Otherwise, we are definitely considering a general-purpose poll/trigger feature: basically, a poll will periodically occur, and if a condition is met, trigger some sort of event. This would be shared across multiple products, and the usecases might vary based on the product. One motivation to develop this feature is that it will allow us to really feature the "BuildMaster is from source to production" story, which is becoming more popular again. Most people didn't want that, but now the pendulum is swinging back to it, now that source code tools (like Git) are integrating (totally inadequate) build/release features. In any case, none of this is all that "immediate", but I wanted to share reasoning to you about this, and solicit your feedback. Of course, if you need to create "legacy components" we can help you do that as well. We don't plan on removing those from BUildMaster, just hiding them so no new users can access them.

You can mirror ProGet feeds, but we don't have a Maven <> Maven repository option just yet.

It's a "401" error, which means "not authorized" In this case, you could have the wrong credentials in Yarn (or no credentials). Note that "Windows Integrated Auth" is not supported by npm or yarn.

It was generalized to use ProGet's API keys which have more granular security options: https://inedo.com/support/documentation/proget/feeds/nuget#nuget-api-key