@stevedennis thanks, that did the trick! I

@stevedennis I didn't explicitly enable it, but it does seem to be enabled on those feeds indeed.. I did indeed use the API / pgutil.

I get the following when trying to click 'change'.

Only seems to affect Docker feeds; I've got other types of feeds (e.g., Helm) that I also configured; those don't show the same error when opening the GUI to edit.

@stevedennis thanks for the quick reply.

Something seems to going wrong then... For example, I've got a feed (backed by a connector) proxying docker.io images; essentially the same flow I'd like to use for our internal images.

I've pulled images through it with S3 enabled since the beginning. I'm expecting to see some data in there;

I've tested the storage, and it seems to be happy;

It does seem to be storing manifests, but no actual images;

I have caching enabled on the connector;

Inspecting ProGet itself (using the Docker image); it seems to be storing everything locally in /var/proget/packages;

Any idea what might be going on?

Hi all,

I'm currently in the process of migrating between ProGet instances; we're moving from a couple monolithic feeds to narrower, team-managed feeds, as well as moving from locally stored artifacts to S3-backed storage...

Since we've got a large amount of build pipelines & deployment environments that need to be updated, we figured that we could proxy our "old" instance, using connectors + team-specific filters. This works for switching endpoints easily, without a big-bang migration. Our teams can then progressively update to push to the new instance, while old tags are pulled from the old one. This also saves us from pulling data we don't need to the new instance.

One issue has come up however; the cached packages seem to be stored directly on disk, instead of being pushed to the (configured) S3 storage on the feed. Is this intended, or can it be reconfigured?

A related thought, to make our migration more 'resilient' would also be to automatically create a local repository when pulling via a connector, if that could be an option. However the S3 issue still remains; we won't be able to keep all our images locally.

Would you have any pointers on dealing with this?

Thanks,
Cyril

Hello!

We're using pgutil to programmatically manage our ProGet instance, which we're planning to use to proxy APT/Debian repositories. Creating a feed+connector works via the UI, but I can't seem to find a way to set Debian feed-specific properties, such as components & distribution, via pgutil or the API. Is this possible?

We're setting up GitOps-style management of our ProGet instance; working great for other feed types, so would be fantastic to be able to do so with Debian connectors too!

Best,
Cyril

Hi Inedo team; I'd like to confirm the restrictions for ProGet licenses, and how they apply for automated testing. I have already read the documentation at https://docs.inedo.com/docs/proget/administration/license

We're currently running a Basic licensed instance for a production environment, and a Free licensed instance for testing configuration and automations. These are automations where ProGet itself is the target.

We'd like to implement some testing via CI/CD pipelines, which would involve spinning up a ProGet instance and programmatically configuring it. No technical blockers, however there is a concern on whether this would be acceptable within the Free license terms. This would technically be a single instance, though short-lived and frequently recreated. Does this fit within the usage restrictions?