Hi @andy222 ,

The Git issue should be resolved; that was related to some authentication issues with newer versions of GitHub Enterprise. It broke a lot of tools across the board, apparently. Anyway, I see it just got fixed today. Check out BuildMaster 2023.10-rc.5 if you can

How about pushing a NuGet package instead? That's a much more common scenario (folks migrating from Octopus), and it's one we're going to add some good first-class support for in BuildMaster 2024.

Thanks,
Alex

Hi @andy222,

Very sorry for the frustrations here - it's frustrating for all of us too (me especially) when it doesn't work

Just to give some context here --- we made a huge investment in BuildMaster 2022/23, and one of the areas was a major improvement for how we integrate with ProGet. The feed::FeedName and directory::AssetDirName convention is brand new, and it's an improvement/simplification on the "Secure Resource" convention that you discovered. However, both conventions -- as well as directly specifying those values on the operation -- are still supported. There's a lot (too much?) flexibility.

Unfortunately this particular scenario / use case (downloading assets from ProGet) was simply not one that we focused on:

• Uploading assets is uncommon, but still happen
• Downloading assets is rare... and not something I've seen done in BuildMaster much

NuGet packages are not uncommon when coming from TeamCity/Octopus model. Regardless, we didn't focus on this use case. We felt most new users are seeking Git, .NET, Maven, Build, CI Import, and Docker, so that's where most of our effort was focused..

That said.... I would love to make your scenario / use case something really easy to set-up, so hopefully that will give you the confidence to continue!

In this case, it's a "trivial problem" where something just didn't get "wired" up the right way. I can clearly see from the code that the ApiUrl parameter is not being wired-up as it should be.

We'll get this fixed ASAP, just an extension fix. We just need to set up the scenario and make sure it works on our end first.

Cheers,
Alex

@emer-connelly_2117 very cool, thanks for sharing!!

Hi @sebastian-lieschke_5424 ,

Thanks for the request; this is something that is close to requesting a new feed type, so I'll use that rubric to decide.

As we wrote in that link, new feeds can be very time-consuming to research, develop, document, maintain, etc. Like with all software, even estimating the cost is costly - so we can't really even begin the initial research until there's sufficient demand or market opportunity to justify the possible investment.

To be honest, I don't see there being much demand or any market opportunity for this. Time will tell, and maybe someone will comment on this in the future. But for now this seems really niche.

That being said - I took a quick look at the document you linked, and I don't see API docs (i.e. those missing endpoints you mentioned). Maybe it's something as simple as a basic JSON document. Maybe it's an absurdly complex and undocumented API.

However, if you can figure how the API works, and it turns out to be something like a simple JSON/XML index file.... and you can prototype/fake that using a static file inside of a ProGet Asset Directory... then we can likely implement that quite easily.

I know that's how RPM and Helm Chart feeds got started long ago :)

Alex

Hi @sebastian ,

This will all get a pretty big overhaul in ProGet 2024. I'll share the details in the coming weeks, but here is a sneak peak:

This is what it would look like when viewing the MyFeed licensing rules:

The "Scope" refers to the name of a policy, and you can create shared policies, so this would mean shared sets of licensing rules. You can also bulk-edit license rules on a policy:

I think the new features will change your workflows a bit... maybe you'll use "Warn"? Or perhaps maybe you won't block Non-compliant packages? So for now, I'd wait and see :)

Alex

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370

Took a bit, but CRAN (R) feeds have arrived

https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

@mrbill @entro_4370 CRAN (R) feeds have arrived

https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

@dima-tinte_1260 @rob-leadbeater_2457 @sdohle_3924

Debian (Apt) Connectors are here! Check out this blog article to learn more:
https://blog.inedo.com/inedo/new-debian-feeds/

@shfunke_1795 @jrottmann_6111 @sdohle_3924 @bahues_9728 @appplat_4310

Thanks for insight into this! I'm happy to report that starting in ProGet 2023.22, you can create Alpine (APK) feeds with connectors :)

@paul_6112 said in Do you plan to upgrade JQuery in a future ProGet release?:

This was picked up by nessus on BuildMaster v7

Lol wow - that's ridiculous

As I mentioned before, it's a forked library thus not vulnerable. So I suppose you can continue reporting it as a "false positive" to whoever seems to care, and perhaps we'll also just edit the version number out to appease that the security tool

Thanks @carl-westman_8110 , I appreciate the feedback!!

As someone coming from Azure Artifacts, I'd love to get your impression on our draft ProGet vs Azure Artifacts page - we're slowly starting to try to articulate the high-level differences and benefits to ProGet. But I swear marketing copy about the software is harder to write than the software itself

We also have BuildMaster vs. Azure DevOps comparison page too, though it's quite a bit more involved.

Hi @carl-westman_8110 ,

Thanks for the feature request! I'm afraid this one's a bit too niche to implement as described, and this use case isn't something we'd want to support for Universal Packages.

However, Asset Directories are a good fit for this, and one of the use cases is a Static CDN. So that means you could use it for web assets like docs if you wanted.

You'll still need to publish the docs like you would to the other webserver. And of course you could hyperlink to the document root from the universal package description as well.

Cheers,

Alex

Thanks for the feedback @philippe-camelio_3885 !

The Applications page is "ancient", and was originally designed to show "what build is in what server/environment". That was super-useful at the time, and I suppose still is, depending on the use case.

But with multiple pipelines per application (like you have now) this view isn't so useful. I'm definitely open to redesigning / rethinking some of these dashboard/aggregate pages.

This is something we can think about for v2024 (since v2023 is just a couple weeks away ). I've put a note onto our roadmap planning board, and may jump back or email you directly for some feedbakc/insight

@shayde @sebastian really appreciate the help, we'll get this incorporated ASAP !!

Hi @jchitel_9895 ,

Thanks for the additional info! We "moved" your new topic back to this one, since we link these on this page in the docs and want to keep everything in one place: https://docs.inedo.com/docs/proget-feeds-other-types

Keep in mind that feed types are a significant initial and ongoing investment (it's a product in a product), and at first glance, Homebrew doesn't seem to make any commercial sense.

First and foremost, there doesn't seem to be a market here. Homebrew itself isn't commercialized. They tried a Kickstarted from 2013, but it seems to remain a hobby-type project. Compare that to Chocolatey (which may be a little older, and also did a kickstarter I think) -- they now have a decent size fulltime staff now.

But secondly (and on a technical level), there isn't a "Homebrew Repository" or "Homebrew Server" - as you mentioned, it's Git-based - which means all it's doing is cloning Git repositories, and probably using tags and specific repo layouts to determine packages.

Cheers,
Alex

Thanks for clarifying @philippe-camelio_3885. I see the issue in the code now. I think it's been this way for quite a while

On the View Page, there seems to be some special handling for credentials;

return "ssh-rsa " + Convert.ToBase64String(cred.PublicKey);

I'm just going to delete the "ssh-rsa " bit, since apparently that can be incorrect. That's an SDK change actually, so it'll take a bit to be reflected in the products.

On the View Secret Fields page, we're just coercing the value to a string:

return InedoLib.UTF8Encoding.GetString(bytes);

That doesn't seem right either, but I'll just leave that as is. I know we redid that page in BuildMaster and eventually will bring to Otter.

There probably should really be a special page altogether for this type of credential, instead of using the generic "Edit credentials" page. Not a big priority but perhaps some day :)

@hwittenborn awesome! I'm not sure if you saw it yet, but we have a new API called the Common Package API; I hope to fold in Promotion, Repackaging, and Deployment under this so it can be consistent

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).

Curious ... why not just enable non-interactive login on the servers? Seems like both ought to be enabled in most cases, right?

Hi @sebastian ,

Thanks for the feedback; that's my understanding of the scores. The main value is time savings in manual assessment. I wish it was easier to get in, and it's too bad our datasets don't have it. We'll need to review this in the coming months, since it involves a lot more work on our end to refactor things.

As for Visual Studio, one of our engineers here just prototyped that, and I think we'll do it. That's much simpler and easy to sneak in a maintenance release :)

In the past, it wasn't possible in Visual Studio before (they used a different API that was nuget.org-only), and it wasn't feasible in ProGet due to the indexing. But now it's much easier.

I think this will be one of those "freemium preview" features. Not that it impacts you, but we're thinking that free users will get a link to a page in ProGet that's like "vulnerabilities are paid feature, here are the benefits, etc. To see which vulns the linked package has, navigate to feed, click here, etc. Paid users can assess, block, etc."

Paid users would just link to the package or vulnerability or something. Just our idea figured I'd share ;)

Cheers,
Alex