Ah, I see what happened. The logic to display that particular should be tab BuildMasterConfig.Legacy.ScmTriggers || BuildMasterConfig.Legacy.UrlTriggers. I fixed it! FYI - we still ship new maintenance releases of BuildMaster 6.1, but no "new features". The main goal is to make sure we have everything to help transition the migration to 6.2/7.0, so if there's anything we can add please don't hesitate to ask.

Ah yes, thanks. Time to configure that side of it then.

Can confirm the latest version resolves the issue. Thanks!

Looks good! I had to create a volume mount for /var/proget/extensions to get the extension upgrade to persist, but it seems to fix the problem. Thanks!

FYI @alexjeffreys_3320 this is currently targeting 5.3.26, which is planned for April 2 (PG-1914) - we'll update if it gets tricky or problematic

I didn't have the problem the next day, so I can no longer replicate it. If it happens again, I'll re-post with logging details. Consider it closed. Thanks.

@Stephen-Schaff I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries. You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12

Hello, All good, thank you for the support, the investigation and the oncoming fixes. Cheers, Jérôme

@emejibka_8689 got it, thanks! So, ultimately, you were able to get it working by adding that? I'd love to get a NGIX Guide together that walks through how to do this. What did your NGIX configuraitn end up looking like?

@stevedennis Thanks

Great !! Thanks

@Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed: It is possible that you are underestimating the value that enterprises place on governance of their processes. It's really valuable, but from a marketing/sales perspective, it's hard to "compete" with the likes of ServiceNow for governance improvement. Containers are already too much in the weeds for the folks with governance problems/pain points... and they can "just throw a guy they trust to manage the details, like Stephen" @Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed: Multistage Dockerfiles to not pass any part of the Dockerfile that was used from a previous stage on to the later stages (aside from any files copied). That makes sense, but you could still validate that containers "inherit" from a known base image. In ProGet, you can navigate across base images.

Hi @atripp Just to let you know that I just upgraded version 5.3.24 and can confirm that this issue is now resolved! Thanks so much for all your help! Thanks Simon

Good idea Thanks

@JonathanEngstrom Otter v3 is still really early in the release cycle (closer to what folks used to call "beta" than "stable"), and we're getting the bugs worked out. We also fixed a bunch of bugs (unintended behavior) while testing v3, so it could be an unexpected change. Please let us know specifically what you find so we can look to get things working. I'm not really sure what you mean by "Ensure Server $servername". The only thing you should need to do is change PSEnsure -> PSEnsureScripts to get those scripts working, but the single-script will be a lot better once you get a hang of it. We plan to put a lot of work in documenting this new integration, and coming up with tons of examples to help folks verify the configuration and configure their servers. The main real advantage to the new PSVerify/PSEnsure mechanics is that you can write a single PowerShell script to both verify and configure servers, and more easily create/modify/test/share those scripts outside of Otter.

Thanks for the reply, this is exactly what I was looking for! I guess the piece I was missing was that there were additional permission options that aren't exposed by default, but that I could bring in by adding a new task. The links you provided helped me fill in those gaps, so thanks again for that!

@Joshua_1353 sorry about that, I missed it. As you can see from the flurry of commits I just made to your repository, I'm simply not experiencing the problem. I tried this with both a Secure Credential, and without. Here's what I discovered during my testing the Git Raft Editor isn't very clear about "keeping the same password" if it's unchanged, but that's what happens GitHub doesn't seem to look at the username? I entered invalid usernames and it worked fine the PAT permission required seems to be "public_repo Unless you have something that's "doing something" between Otter and GitHub, I think that: you made a typo or something in your PAT; you can't have any spaces, it must be exactly a PAT, so make sure to edit and save it your PAT doesn't have right permission From here, about the onloy thing you could do is attach a proxy server like Fiddler between Otter and GitHub, and see specifically what traffic is flowing through. But like I said I think it's one of the above to

@nuno-guerreiro-rosa_9280 the API you referenced is the "NuGet v2 API", and we simply follow the specification when we implement their API. In the same way, we follow the Docker API specification, which does not provide a way to query a docker image in the way you'd like. I think you have a good point, but it's not our specification or decision, but Docker's There's not much of a demand for a ProGet-proprietary API for packages at this time, but if you can help us understand the value of this, then we can better considering it - https://inedo.com/open/feature-requests

Hello, This is a bug, in that PSVerify shouldn't show up on the statement list. Instead, your scripts should, in a manner like this, with a Script Execution mode: [image: 1614579688039-f659bdca-9a55-4b9c-81bb-77ee357e8e66-image.png] Then, they'll look in Otter like this: PSVerify VerifyFreeSpace ( MinimumFreeGB: 24, DriveToVerify: C ); Here's how this script works behind the scenes... <# .DESCRIPTION Verifies that an hdars server has the required and expected configuration .AHDESIREDVALUE True .AHCURRENTVALUE $AmpleFreeSpace .PARAMETER DriveToVerify The drive letter (such as "C") for what to verify .PARAMETER MinimumFreeGB The minimum free space required on the drive, in gigabytes #> param ([int]$MinimumFreeGB = 20, [string]$DriveToVerify = "C") $ActualFreeGB = [int]((Get-PSDrive $DriveToVerify).Free / (1024 * 1024 * 1024)) $AmpleFreeSpace = $ActualFreeGB -gt $MinimumFreeGB And for reference, the additional help parameter descriptions... .AHDESIREDVALUE This is what you wish the configuration value to be. When not specified, the value of $true is assumed. .AHCURRENTVALUE This is the actual value of the configuration. When not specified, script's output is used. .AHCONFIGKEY This is the "configuration key" used by the script, which is a string that uniquely identifies configuration on a server. It's like a file on disk (a file is uniquely identified by its name), or the name of an IIS Application pool (an application pool is unqiuely identified by its name). Optional. When not specified, the name of the script is used. .AHVALUEDRIFTED This is an indicator as to whether the value is considered drifted. When not specified, it's a string comparison of the desired and current value. .AHEXECMODE This is either "Collect" or "Configure", and is only used on PSEnsure operations; it will be ignored (or set to Collect, depending on what's easier to code) on PSVerify. Using a PSEnsure without a .AHEXECMODE will cause an error. The Additional Help items can be specified as a value or a variable; variables will simply start with a $.

I also confirm I didn't get any more timeouts on the latest version. Very good!