Hi @ForgotMyUsername , I'm not sure I'm know where the issue is... can you provide the OtterScript? Or the specific error/logs that triggered that message. The with isolation is supported, and is a checkbox on the advanced tab of the General block. Cheers, Alana

Hi @k-gosciniak_5741 , We've got no clue what's causing that, but definitely some kind of IIS configuration. Ultimately I don't think the request for that file is being passed into ProGet, but IIS is trying to find the file on disk instead (which it obviously won't be). I would guess if you put a file on disk that file would be served via that URL. IT's just a guess. Other things to look at ... MIME mappings, I've seen those do strange things. Maybe there's other IIS modules. It's really hard to guess. It might just be easiest to switch to the Integrated Web Server; you can just uninstall / reinstall ProGet. That won't use IIS then. Cheers, Alana

Thanks

Hello, You can find it under Admin > License Key; here's more information that might be helpful: https://docs.inedo.com/docs/myinedo-activating-a-license-key Cheers. Alana

Hello @jonathan-brown_3775 , This is considered a "false positive", so please disregard those results :) Those are JavaScript files that run inside your browser to display certain charts about feed disk usage in the Web interface; there is no possibility whatsoever of a security vulnerability or attack coming from these javascript files inside of ProGet. Thanks, Alana

Thank you @dean-houston! A nice and easy way to get around this requirement. We had been thinkin' way too complicated ;)

Hi @pooms_7365 , Thanks, I found where the error is in the code; it was in displaying the "code has not been synced" message. Easy fix (BM-3845) and it will ship in next maintenance release :) And wow... 15gb! Cheers, Alana

Hi @ForgotMyUsername , Checkout-Code operation using Generic Git repository with recurse submodules... I can't reproduce this, but I can see how that issue might occur. Your repository must have a GitLink entry in the target tree (i.e. folder you're checking out), but there's no corresponding reference entry in the .gitmodules file. I've updated that to be a warning., and just pushed the Git 2.2.3 extension. It will be included in the next maintenance release of BuildMaster, or you can download/upgrade now. Every minute an exception appears... Nice find; this will be fixed in next maintenance release (2022.10) via BM-3844 Clone application fails when trying to clone application using generic git repository... I believe this is related to importing "releaseless-builds", and this may be fixed in 2022.9 via an internal commit (i.e. one we didn't log an issue for). Clone does an export then import. If that doesn't fix it, please export the application and provide it to us, so we can inspect the file for issues. Regarding [5], can you send logs? The scenario you describe (existing repo with the same name) is already tested and handled, but there's likely something that's missing.

Hi @ForgotMyUsername , Unfortunately this is not going to be possible to debug with the information you've provided. Except for the misspelling of Certficiate (which would have no bearing on executing the script), a cursory glance of the code shows that everything is otherwise wired up as expected: IisSiteBindingConfiguration.cs IisSiteConfiguration.cs So, I'm hoping you help troubleshoot/debug some more, to show us where the issue is. IIS settings are ultimately stored in the applicationHost.config stored under %windir%\System32\inetsrv\config\. We do not directly work this file (as you can see from the code), but it's the easiest way to review the settings in IIS that Otter makes. To help us reproduce these issues, can you send: (1) Relevant appPool and site elements from the config file (2) OtterScript code that should work with those entries (3) Actual vs expected results in the config file And one note on the bindings... unfortunately this is a difficult problem in general to solve because IIS Sites have multiple bindings, but users often don't want to clear bindings. We used to have a Bindings property (it's still htere) that lets you specify a map, but it was too difficult/confusing to use. Cheers, Alana

FYI; we replied to a critical ticket that duplicated this, but in case anyone is reading this... We have a SQL patch available, but aren't totally sure if it will help. We can send it. We are really struggling to reproduce this in any consistent matter; we believe the issue might be related to sql server's plan caching. we're seeing inappropriate execution plans being used , and then suddenly changing, for the same input. The patch simplifies the queries we're using, so hopefully it will result in a more consistent query plan. Our next idea , is to try forcing some join hints. We're also asking for a backup of the database? That will help us analyze your data. We're thinking maybe you have some unique distributions (like tons of versions for one package, just a few for another).

Hi @ForgotMyUsername, Sorry about that. Looks like the article was changed but not published. I published the updated. Thanks, Rich

Hi @ForgotMyUsername , thanks for the bug report! I logged this as OT-491, and it should be a trivial fix we can get in the next maintenance release :)

Hi @markus-karthaus_8928, The validity check of a certificate ion ProGet is primarily to verify the certificate itself is valid, not if it is valid for ProGet. Any self-signed or internal domain certificate will be invalid by default unless the certificate or certificate authority exists in the trusted root on your server. If it is a purchased certificate, I would check that your certificate's chain is properly installed on your server. If your certificate is a valid certificate but requires a custom certificate chain (many do), that chain will need to be installed on the server for ProGet to validate that properly. A .pfx certificate does not store the certificate chain internally in the file. The browser handles the validation slightly differently, so that is most likely why it seems to work in the browser. When it comes to the .pem file. There are many ways to generate it, but I'm guessing the certificate chain was stored internally in the pem file, which then does not require the certificate chain to be installed on the server. I'm speculating on the certificate chain in these cases because seeing why your certificate is not valid requires more than the screenshots you provided. I would actually need to see your certificate itself to truly validate this. Lastly, when it comes to using a .pem file, .NET tends to be very picky about it's format. It is not as forgiving as other frameworks. If you look in the "HTTPS Binding to a Port (Advanced) (Experimental)" of our HTTPS Support on Windows documentation, we have instructions on how to create a .pem file from a .pfx. I'm not sure if that is what you followed, but that is the simplest way we have found to generate a .pem file that works with .NET. Hope this helps! Thanks, Rich

I pulled the ci.4 image and that fixed the issue. I haven't noticed any other issues, so I'll just leave the ci version installed until the next ProGet release. Thanks again for the quick fix.

@reincarnator247_4909 If you open a ticket can you post it here so I can follow along as well. Or do we have a solution? To me, a call the the /health endpoint should always actually check if things are okay, not assume its okay because something is cached.

Hi @h-morgenthaler_3015, Alana was correct, the change was not merged into the 2023 release. The fix, PG-2350, will be released on Friday in ProGet 2023.4. If you need it earlier than Friday, I can push a pre-release version of ProGet 2023.4 for you. Please let me know! Thanks, Rich

Hello, unfortunately we really don't know what the underlying issue could be. Perhaps it's only an error on the "test" button, and the plug-in will work? This is not an Inedo-created plugin, and we're not familiar with Java or Jenkins to know how to to debug it. It should still work (and I know we have some users who got it working), but otherwise we don't really know how to debug it I'm afraid :( The source code is here, but I don't know if it's at all helpful: https://github.com/jenkinsci/inedo-proget-plugin Cheers, Alana

Hi @jimbobmcgee , The "Secret key" field is just an arbitrary string that needs to match on both the Agent and the Otter Server; it needs to be unique across your servers, as its used to uniquely identify an incoming agent connection. The UI generates a random string, but you can enter whatever you'd like. There needs to be a Server record on the Otter server (i.e. on the "Servers" page) before an agent can connect to Otter. This is true for either Incoming or Outgoing communication modes. This is often called "server registration". One option is to servers self-register in Incoming mode; you can have the the following script on first boot: Generate a random string ("secret key"); you could use a GUID use the Infrastructure API from the server to "register" the server using that key edit the agent configuration file to have that key start the Inedo agent service Hope that helps, Alana

I believe this has already been fixed as part of PG-2343 in v2023.3, which we are releasing today. In addition to being slow, the NuGet queries responsible for handling latest versions could return a lot more results than necessary. It didn't lead to incorrect behavior (except with counts) as we still validate and filter results in the frontend, but did cause problems like this.

This is now fixed in 2023.3, which is going to be released later today. Thank you!