Hi @tcochran_0018,
This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.
Thanks,
Dan
Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Hi @tcochran_0018,
This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.
Thanks,
Dan
Hi @kichikawa_2913,
Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week!
Thanks,
Dan
Hi @kichikawa_2913,
Thank you for following up with us and letting us know it is working now. Also, thanks for clarifying the Docker network setup for me. This is related to how we changed the service messenger in ProGet v6.
I took a deeper look into the code and when setting the endpoint via the "change" link, it will override the configuration's shared value. Once that has been set, it will use the configuration associated with that node instead.
Based on your screenshot, it looks like it was using tcp://*:6001
as the shared configuration (even though you said not to), but failed to connect because it was trying to balance amongst the other nodes. If you were using a Docker network, this most likely would have worked because the individual nodes could have listened on 6001 as well.
After reviewing these changes, you would have to change the service messenger address on each service node in order to apply the configuration you are looking to use (which is what you did above).
Hopefully this gave a bit more context to this change.
Thanks,
Dan
Hi @kichikawa_2913,
Thanks for following up and letting us know that you found the solution!
Thanks,
Dan
Hi @claudio_9251,
I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that.
Thanks,
Dan
I see the email, thanks for sending this over! Please give me some time to review and I'll let you know what I find.
@pieter-mertens_0372, your issue may be related. Although both products are owned by Microsoft, they still differ in their implementation. Does this happen for all packages or just a specific subset?
Thanks,
Dan
Hi @arozanski_1087,
We talked it over in our team meeting yesterday and decided to change ProGet to always create a new release when one doesn't exist and add new dependencies when the release does exist. This way that parameter will not be needed. So you will just need to upgrade ProGet to v2022.23 when it is released later today.
As for the Yarn support and scanning multiple package types in the initial scan, we plan to work on that early next week, so we should have something for you soon.
Thanks,
Dan
Hi @itops_6398,
I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look.
With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later.
Thanks,
Dan
Hi @forbzie22_0253,
You can do this using our Bulk Import via a drop path feature. We have a helpful How To Bulk Import Packages Into A Feed From Disk article in our documentation.
Please let us know if you have any other questions!
Thanks,
Dan
This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon.
Thanks,
Dan
Hi @si-peham_2672,
As far as I can tell, it looks like there is still a permission issue with the working directory that is preventing file listing. The workaround to use the --input
argument seems to get past that issue, so I would continue to use that. For your reference, I did test this locally and on a test server, and both worked without issue. If you are interested, here is a link to our code that is searching for the file (https://github.com/Inedo/pgutil/blob/5001174a4c786bb238e8546d18d82fed71cfcc58/Inedo.ProGet/Scan/DependencyScanner.cs#L114). The SourceFileSystem.Default.FindFilesAsync
just calls new DirectoryInfo(folder).EnumerateFiles
and then matches against the name.
For the Specified argument was out of the range of valid values
error, that will be resolved in ProGet 2024.33, which will be released this Friday.
If you have any other questions, please let us know.
Thanks,
Dan
Hi @si-peham_2672,
I think this is related to a recent Audit API bug, PG-2941. We will be releasing that fix in ProGet 2024.33 due out on Friday. Can you please try running that with the --noaudit
parameter? That will bypass the audit portion in the scan. That will at least scan the "requirements.txt" file and create the build, then the audit will then be performed later by ProGet.
Thanks,
Dan
Thanks for the PR! We are currently reviewing your PR and we will be in touch.
Thanks,
Dan
The warnings in the blob layer scanner are to be expected in most images. Not every layer includes a file system. The layer scanner scans each layer for an application database. This will vary from layer to layer.
There was also a bug released in ProGet 2024.32 that was not recording certain layer scanner results properly. This will be fixed in PG-2943 and will be released in the maintenance release this Friday. This may be why you are not seeing any packages found in this container.
Thanks,
Dan
Hi @si-peham_2672,
When you say owner, you mean you have full control on the folder correct? When the --input
parameter is omitted, it will attempt to scan the directory for the requirments.txt
file. I'm guessing that is causing the issue. A workaround you can try is to specify the path for the requirements.txt
file for the --input
parameter and see if that works.
Thanks,
Dan
Hi @itadmin_9894,
Would you be able to share the entire JSON response and exactly what information is missing that you are expecting to see?
Thanks,
Dan
Hi @rhowell_8827,
Thanks for reaching out. I took a look at the promotion code for Debian-based package promotion and it looks like this is due to a recent regression in our promotion process. I have created a new ticket, PG-2942, to track the fix. This is expected to be released next week in ProGet 2024.33.
Thanks,
Dan
Hi @v-makkenze_6348,
I apologize for the delay on our side. After testing these two packages (Microsoft.Web.Infrastructure.1.0.0
and System.Net.Http.Formatting.Extension.5.2.3
), I'm unable to recreate your error. They download fine for my tests. Can you please try to delete these two cached packages and try it again?
Thanks,
Dan
Hi @caterina,
I'm sorry about this. There looks like there was a conflict with another notifier change. I have created a new ticket, PG-2933, to fix this and it will be released in the next maintenance release.
Thanks,
Dan
Hi @layfield_8963,
NFS storage is supported and used by many users. I'm surprised changing that would fix it, especially since the CLI worked and the backend storage would not be different between the two. I will do some testing in our labs on this as well.
Thanks,
Dan