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!

OK, I did a bit of looking around and ProGet is currently very well priced compared to its competitors. I can easily buy two servers of ProGet for the price of single a JFrog license. If needed, I could try to use that to convince my Management to purchase a second production license for use as a Sandbox instance.

@jn_7742 unfortunately, Microsoft has also abandoned Source Server in favor of SourceLink, and they will not add Source Server support to Portable PDB files Technically, ProGet's Source Server works on Linux, but since ProGet can't inject its Source Server urls into the .pdb files, it's impractical to use. I'll let you guess which 20+ year old program is required to inject Source Server metadata into Microsoft PDB files Bottom line, you'll need to upgrade your processes to use SourceLink

I think I have an idea of what is happening here. I think that this issue is actually caused by my other open issue: https://forums.inedo.com/topic/3164/user-seen-as-a-group I noticed that when I am adding any service account user, it is added as a group instead of a user. Actual users do not have this issue. In fact if you look at step 4 in my reply on Feb 12th, you will see that the restriction added shows the user as a group (purple background). Lets suspend this issue until the we have figured out the issue with users being added as groups.

Hi. It's OK to continue with the ticket only.

Unfortunately this is just an invalid package... someone really needs to tell the developers at Microsoft that the developers at Microsoft really want packages to be in SemVer2 format, per the Microsoft documentation https://docs.microsoft.com/en-us/nuget/concepts/package-versioning Microsoft's documentation seems to no longer describe what Microsoft's once documented "legacy versioning" used to be, but we captured it in our documentation before Microsoft removed it. Bottom line, the "." is an invalid character in a non-SemVer2 (i.e. four-part version number) pre-release tag. Hence, why it's getting a 400 error. It used to do that on NuGet.org, too. I guess it doesn't now. We probably won't change this, since it kind of works already., and since it's only one package. But if you email the Microsoft team responsible for that package, they probably will just change their versioning going forward. IT'd be nice if Microsoft documented how their non-SemVer2 packages are supposed to work.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @scroak_6473, ProGet automatically handles creating a temporary API key for use with clair. When ProGet integrates with clair, it generates a temporary key to use to check layers for vulnerabilities then deletes it when the process completes. So there is nothing you have to do to authenticate clair to ProGet. If the key is still there after running the scan, my guess is an error occurred while trying to clean it up. As for the other error you are seeing, are you able to pull an image with that layer attached to it? I can probably create a SQL query for you to link a layer to the image if needed. Thanks, Rich

@philippe-camelio_3885 oh i see; you mean, capture the output of a process or script execution into a variable or something. Definitely something to consider as an enhancement, I think. That wouldnt' be too bad (though the variable could get huge, and rutnime variables raen't realy designed for large amounts of text like that)

Thanks for the update; and the upcoming fixes will certainly make it so that purging is much more efficient on the manual execution side, just in case there's an "Explosion" of executions like this. So right now, my concern is that it's "logging every sync" (once per hour), due to a sort of bug or something. Can you check what's getting logged in Infrastructure Sync? You should be able to see this under Admin > Executions, and see if you can spot a pattern? No rush. The infra sync executions should clearly show a change history of what was updated on the infra side.

Ok Thanks for the reply

@atripp You bet. I'll see what I can do and let you know