Hi @rhessinger , Thank you 7.0.6 is much clearer for the log lines :-) [image: 1627226885746-baa11992-e178-4ee9-ad89-bf6d6b587ab5-image.png] Regards, Paul

Hi @stevedennis , Now tested as working iv 7.0.6 thank you ! [image: 1627226371494-8e4296de-d320-4e06-aeae-f09c265badbb-image.png] [image: 1627226387840-f9e02922-025f-404b-9763-998036313a86-image.png] Regards, Paul

Hi @atripp , Great, thank you ! They are also removed from the Release Overview page. [image: 1627224368665-43b43dca-6470-4aca-a962-7ab0b3db73ef-image.png] Thanks, Paul

Hi @atripp , This is great, thank you :-) [image: 1627224124354-b0b906e5-c7e4-4839-a6ba-7bab029ef7da-image.png] Regards, Paul

No, this is a new deployment. And health check errors only occur on the connectors of Docker Hub and GCR, while Quay and MCR are work final. At the same time, I can pull the image directly from gcr.io.

@atripp said in Proget software removed but still showing in hub: C:\ProgramData\upack\installedPackages.json) Brilliant that did it thank you. It would be nice to have a reinstall/repair.

Hi @hwittenborn , I can definitely see how this could get annoying; this has been the design of our products for quite a while, mostly for simplicity/security reasons, and there hasn't been much demand for changing it. We're definitely open, so if other users are interested we'll certainly consider it. Most administrators prefer "short sessions" (i.e. logged out at browser close or with no activity) for their own management simplicity; if we were to add "long sessions" (the "Remember Me" checkbox using persistent cookies), then administrators would need to worry about which users are "logged in", for how long, and terminate those sessions. And then we'd have to add all the features to support that capability - so nontrivial. Best, Steve

@rhessinger Hi Rich, I've tested 7.0.6-rc.2, this is now saving the template, thankyou. Regards, Paul

@atripp Thank you very much! I upgraded to ProGet version 5.3.32 (Build 11) and the error is gone.

I thought I did have anonymous View/Download on that feed, I did not. It's working now with the Api Key I set under administration, thank you!

@kichikawa_2913 glad it's working now, you seem to have found the issue. FYI, you can also configure that value from Advanced Settings page under Admin.

@atripp Hi Alana, Sorry for the delay; I had not checked in as I was watching for the v7.0.5 release.. Extension v1.10.5 looks good to me in solving this problem; thank you. Regards, Paul

Hi @jharbison_7839 , We definitely need to update our release template documentation, but in the meantime... The "Allow all variables to be added" option allows you to freely add/edit/remove variable from the Build/Release pages, regardless of restrictions set-up by the Release Template. When it's not checked, only templated variables may be configured. This is not checked by default on new release templates, and prior to v7, there was no ability to edit variables using the template. So, checked = just like it was in v6.2 and earlier, and not checked is temlate-based editing. Alana

@atripp The links are very helpful... BM always showing the time in UTC...though I updated the server time to be localtimezone. So, the scheduling automatically changes the next run to be in the UTC format... once this is understood, I see that the cron based scheduling is working as expected... Thanks for your help.

Hi Rich, I'll try what you suggested, thank you. We tried to upgrade NPM client, unfortunately this will use also a newer version of Node.js which has a different error handling that caused all our unit tests to break. So we skipped that option until all tests are fixed. The issue appears since one year now. It disappeared for 2 or 3 months but always came back. Thanks, Jana

Hi, Please refer the below blog. You may have an idea on Semantic Versioning. https://www.meritedin.com/robust-api.html Please don't forget to take a look on the videos listed on their playlist.

@rhessinger It looks like I was on a wrong menu or something, and it thus wasn't showing up. I was able to dig around a bit and found the option though. Thanks!

I'm glad you got it working! I had forgotten that flag was even added :/ I'll chat with the docs team to get things clarified in there, or maybe see if we can change the default to enable v3 by default from now on. Thanks! -Greg

Hi @hwittenborn, Thanks for the extra information. It is very much appreciated! Are you saying the file fails to get added if you save it under the filename {feed-name}.pub? I actually used it as a gpg file extension, but honestly, your solution much better. The file extension doesn't actually matter that much. Once it is added using apt-key, it just extract to contents and stores them in their keyring. You can see this by running sudo apt-key list. I was more stating that in order for it to work for me on Ubuntu 20.04, I had to have everything named as the lowercase feed name in order for it to work for me. Although, I'm not sure if the lower case part matters. For example, for a feed name defaultdebian, I ran this: wget -qO - http://proget.localhost/debian-feeds/defaultdebian.pub | sudo apt-key add - echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/defaultdebian.list sudo apt update As a test I changed echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/defaultdebian.list to be echo "deb http://proget.localhost/ defaultdebian main" | sudo tee /etc/apt/sources.list.d/proget-defaultdebian.list and that actually wouldn't work for me. This caused a bunch of warnings when I ran sudo apt update. For some reason this only mattered in newer versions of apt though. All in all, I will update the documentation to correct your command (adding the missing '-' ) and to include the updates to the naming. Hopefully, this will be clearer going forward for other users. Thanks for all of your help! Thanks, Rich

Hi @hwittenborn, Thanks for the additional information. We talked about this in our team meeting this week and we decided we are going to clean up when restarts are needed and we are hoping to give better messaging to the user when a container needs to be restarted. Some of the restart requirements are leftover from previous requirements that have since changed. So hopefully we can make this process a bit easier in the future. Thanks, Rich