Hi @marc-ledent_9164 , This is available in InedoCore-3.0.4, so if you go to Admin > Extensions, you should be bale to update. thanks, Alana

Many thanks, Alana! I can confirm, that the proget:24.0.37-ci.2 container image works like a charm Thanks for the quick fix! Fritz

Hi @mhelp_5176 , I haven't investigated BitBucket Cloud any further, but it sounds like there's an issue with the integration -- and it's definitely something we can look at later. My guess is that it's some kind of change to the API/authentication. But we're all pretty focused on getting ProGet 2025 out the door, so it'll have to be after that. That said, the main difference between connecting to a "Git host" like GitHub, GitLab, Gitea, BitBucket, etc. vs a "generic Git repository" is that there will be some intelligent drop downs to help you select a repository. There are a few other differences as well, but mostly it's UI. So for example, on a GitHub connection, you'll see a list of organizations and repositories, and then would select the one to connect to. Compare this to the "Generic Git repository", where you simply paste in the repository clone url. But in either case, you need to configure each repository connection individually; typically each application will have one repository, which is why this is part of the application creation process. It's definitely not a common practice to be able to "pull in all the repositories in a workspace" at once - that's not really how Git works, and it would involve some kind of script that iterates a list of repositories and clones/updates each one indivdiaully based on configured remotes in subfolder., Cheers, Alana

I've now found a cleaner way of adding this entry to the host file... If using docker run, add the argument: --add-host=<host_server_name>=127.0.0.1 if using a docker compose file, add an entry: extra_hosts: - "<host_server_name>: 127.0.0.1"

Great, thanks!

Hi @steviecoaster , You can use pgutil for this: pgutil settings set --name=Licensing.Key --value=XXXXXX This is in the Configuration table FYI, which is what pgutil settings does Thanks, Steve

@michal-roszak_0767 said in Pull Maven artifacts - invalid version: Next victim: https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/ jeeze, what a mess! Well, there goes any hope of using v[0-9]+ -- they just straight up use random strings as version numbers. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/Neumann-SR9/ Open to ideas, but based on the URLs alone... I don't see a good way to identify one of these as an artifact and the other as a version of an artifact.

@michal-roszak_0767 it wouldn't hurt to start a new topic about it, but it's design decision so you'd have to make a good use case for it :) I can't find the discussion (maybe it was internal), but the idea is that "generic website connectors" for Asset Directories are a poor solution for "offline" environments. A "generic proxy" like ngnix will always be better in every way.

Hi Steve Thanks for your response. I've read the documentation and for the client part I followed the Microsoft documentation: https://learn.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg After some testing, I've found the problem: I had to add /v3/index.json to the URL. Now the package and the symbols are pushed to the server. The ProGet UI shows the correct URL under API endpoint URL:. I'm not sure why my build script was using the URL without v3. Maybe it was different in an older version of ProGet or I just made a mistake somewhere? Interesting is that pushing "worked" when using the URL without v3 and v2 API disabled for the feed. Maybe the client NuGet client contains some logic to only push the snupkg file when it detects a v3 source?

Hi Steve Thanks for your answer. I saw this in the doc and thought it will use v3 https://learn.microsoft.com/en-us/nuget/api/search-query-service-resource It is possible to search for packages available on a package source using the V3 API. The resource used for searching is the SearchQueryService resource found in the service index. In this case, sorry for the question and please forget it^^

Hi @e-rotteveel_1850 , Just as an FYI, this was much more complex that it seemed, and we ended up creating a whole new feature to address this called Feed Integrity Checks. This will shipped in friday's maintenance release, and in theory should spot and allow you to resolve the issues:https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-feed-storage#feed-integrity-checks Alex

Hi @sergio-gonzalez_0157 , Typically, Deployment Targeting is done in the Pipeline: https://docs.inedo.com/docs/buildmaster/deployment-continuous-delivery/buildmaster-pipelines#deployment-targets This way, you don't need to put for server or anything in your script. So, my guess is that your Pipeline is actually targeting the ProductionServer (but not running anything on it, except intializing the agent), but your script is targeting the BuildMasterServer. -- Dean

Hi @michal-roszak_0767, Oh that's a whole lot of connectors and this is most definitely going to cause some performance issues. Remember that ProGet needs to forward every request you make to all 10 of those servers, and some of these repositories will not respond very quickly. Like JCenter was deprecated/retired a few years ago, and I can't imagine is performant at all. Especially for things like metadata requests. Maven is not a very patient client and will time out while waiting for ProGet. There is really no way around this. You'll need to use less connectors. -- Dean

@michal-roszak_0767 those are also invalid versions and you should never upload them to a feed (repository) directly; see https://docs.inedo.com/docs/proget/feeds/maven#snapshot-versions The code has already been fixed and the maintenance release is scheduled for next week. We could get you a prerelease, but I don't think your developers are manually uploading artifacts using the Web UI? If you want to upload artifacts with bad versions now you can just use the maven client (e.g. maven-deploy) or just do a basic PUT of the file to the desired group/artifact-id.

Thanks @dean-houston! That's good enough for me. Looking forward to trying the new migrator once it lands, sounds really really good!

Hi Steve, I fully understand. I will carry on using the existing format then. Thanks for the tip regarding use of pgutil! Thanks, Stefan

@dean-houston I just upgraded to the latest version and it worked perfectly now. I can update packages of more than 2 GBs without any problems. Thanks you so much!

Hi, @rhessinger Works like a charm :) Thanks. Regards, Michal

Hi @stevedennis Thanks for the quick response and fix.