administrators

@sigurd-hansen_7559 wow very cool! We didn't anticipate anyone would customize these templates beyond adding a variable or two, so it it didn't seem to make a lot of sense to invest in a proper editor (like we have in the other products)

Anyway, it'd be interesting to see what kind of templates you develop.

Hi @alkhleif_2585 ,

There isn't much demand for this kind of feature (I think we've only seen one or two requests for this over very many years) so it's not on our roadmap.

And it's unlikely we will add it to the roadmap considering that it would be quite costly to build, support, and maintain. Especially considering that we'd need to support all of the major "vaults" out there as well.

It doesn't seem to add much value to ProGet as these types of read-only credentials can be very long living (several years) without any security risk, and take just a few minutes to rotate when needed.

That being said, you could probably write a "sync script" pretty easily that continuously updates the connector credentials by connecting to the vault and then updating it via the API.

Cheers,
Steve

Hi @vdubrovskyi_1854 ,

Without knowing which specific package you're referring to, it's hard to give a more specific example.

Historically, Packagist was effectively a database of "GitHub Repository pointers" and Composer was effectively just a wrapper around the Git client. They can both still operate in that mode, and needs to for older, non-standard packages. I suspect that's the type of package you're referring to here.

ProGet's Composer feeds work with "packages" (i.e. not the GitHub pointers), which account for nearly all of the modern packages on Packagist.org. For the small number of packages that don't follow the standard (mostly older, legacy packages), you'll need to download them, properly package them, and then upload them to follow the standard.

Unfortunately there's no technically feasible/sensible way to solve this problem - since it would require ProGet to serve as a GitHub pointer database, which just doesn't make sense.

Cheers,
Steve

Hi @Nils-Nilsson ,

It's possible but it's quite complex; there are dozens of variable/macros that rely on context (some will give an error) and none of them have built-in dummy data. That would make templating expressions like <% if %> or <% foreach %> difficult to test.

In theory, you could enter a large box of variable expressions (like $FeedName=fake-feed)... but at that point, it's just easier to test things by performing the actions on a real package. A quick pgutil packages delete + pgutil packages upload script works great for that... that's how we test.

Thanks,
Alana

Hi @joris-guex ,

Thanks for the detailed information; I was able to reproduce the error pretty easily thanks to that.

It seems to be happening when parsing a Dependency entry in the .toml file (missing version), but I can't figure out why since the version appears to be there. It also shouldn't cause this beahvior for this particular error.

In any case, we'll get it fixed via PG-3303 in an upcoming maintenance release. !

Cheers,
Alana

Hi @brandon_owensby_2976,

It's a bit confusing, but the message "{name}" is not a valid DeploymentScript identifier for the "global" scope. will occur when:

• a script is being executed in the global context (as this is case here)
• the {name} does not start with global::

I know you mentioned you pre-fixed with global::, but these scheduled jobs can be a bit tricky to test. It's possible that the old record (without global::) was queued up.

To be totally certain next time, I would stop/start the service so that there's nothing that gets queued up.

Thanks,
Alana

@Ashley thanks for letting us know!

Hi @brandon_owensby_2976 ,

Thanks for the feedback, we appreciate it :)

There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it.

In general, the way I would try to configure is:

• consider using a releaseless-build if you don't yet know the release it's targeting
• use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge
• clean up the builds aftewards

That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky.

We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test:
https://buildmaster.inedo.com/applications/136/overview

No idea if that's helpful, but just FYI

Cheers,
Alana

Hi @brandon_owensby_2976 ,

Looks like this is a regression in BuildMaster 2025 from a library upgrade; we will address it via BM-4017 in an upcoming release, either this Friday or the following cycle.

Thanks,
Alana

Hi @pg_user_8607 ,

Nice find with that image; that makes it easier to demonstrate :)

This is unfortunately another "weird docker thing" that would requires a substantial amount of internal model changes to properly address. That's not on our roadmap at this time.

The image you found (inedo/buildmaster:25.0.12) is a so-called "fat manifest" (i.e. a manifest that points to another manifest). As such, there are zero layers (blobs) and thus the sum of all blob sizes is zero.

The 25.0.12 manifest points to e84148156b3e, which is an untagged image. You can see this on the "Sub Images" page:

The /containers page does not show untagged images.

In the past, "fat manifests" were rare - but the default Docker build tools default to create fat manifests, even if there's only one image. It's something we will likely address down the line, it's just not in the roadmap now.

Thanks,
Alana