inedo-engineer

Hi @kc_2466 , nice catch! We'll get it fixed via PG-3060 in the next maintenance release!

Hi @m-lee_3921 ,

Thanks for the heads-up; we'll get this fixed via PG-3059 in the next maintenance release (scheduled for later today).

And you're right -- its basically the same issue. SQL Server silently truncates string values whereas PostgreSQL does not, hence these errors.

We decided to not auto-truncate, since it's better to know about these cases than not. In this case, it's a IPv6 address that was longer than the 20-character limit. We plan to refactor API key logging at some point, so we'll just continue to truncate v6 IPs.

Thanks,
Alana

Hi @carsten_1879 ,

Can you try out buildmaster:25.0.0-ci.23 container image?

I would do a new/fresh installation - new applications created in it should use the new Git library. It seems to work, but would like to see if it works for you as well.

Thanks,
Alana

@it_6176 thanks for sharing!

You're right, we did not consider this usecase when designing Debian connectors. Our "default mode" in ProGet is "dynamic indexes", but the quirkiness of the Debian repository "API" and obscene size of operating-system libraries make that impractical when there is a lot of feed activity (i.e. packages being added to the feed via caching).

We are going to redesign this at some point, and allow for some kind of "periodic indexing" for some connectors. That would be run as a job, as opposed to triggered by a user's request.

As for the database.... we've had one other user report that those SQLLite databases "blew up" as well, and our conclusion is that "something" crashed at the wrong time. Probably, due to the resource overusage? It has something to do with the WAL Files, but we're not totally sure.

I think we just need some kind of regular clean-up for these "huge" connectors so the database doesn't get so huge.

Hi @caterina ,

I agree and there doesn't seem to be any good usecases or official guidance from npm tags command, but we do not recommend using them: https://blog.inedo.com/npm/smarter-npm-versioning-with-semver/

From the api/technical standpoint, npm tags are a little weird -- a package themselves doesn't contain tags. Instead, the registry has a key/value tag store. By convention, the store has keys like latest and values like 4.8.1, but it seems to allow anything? At least from data we've seen on npmjs.org

In any case, the npm client seems to set a latest tag, so we'll just support that use case then.

FYI here is the logic/code I added:

        var tags = await this.GetPackageTagsAsync(purl.Name, false, cancellationToken: cancellationToken);
        if (tags.TryGetValue("latest", out var latestVersion) && latestVersion == PackageVersion<SemanticVersion2>.Parse(purl.Version))
            await DB.Npm_SetTagVersionAsync(toFeed.FeedId, purl.Name.Id, "latest", purl.Version, DateTime.UtcNow);

It sets the latest tag on the other feed if the current feed's latest tag points to the package you are promoting.

Thanks,
Alana

Hi @caterina ,

This behavior is expected as only the package itself is promoted, not repository metadata.

I'm not an npm developer, but one concern I have is that the latest tag doesn't always refer to the most recent version of a package? It's a little confusing to be honest, but I read that developers will sometimes use latest to "pin" what they feel is the most stable version?

I don't understand why this is a practice in npm, but I think this is probably an exception. So, we will change the behavior via PG-3057 such that the "latest" tag is set on the new feed when promoting latest-tagged npm package.

This will be in the next maintenance release of ProGet 2025.

Cheers,
Alana

Hi @phopkins_6694

Looks like this is a regression in ProGet 2025; we'll get it fixed in the next maintenance releaese, scheduled for this Friday via PG-3056

Cheers,
Alana

Hi @kc_2466 ,

Can you share how / why you're create Universal Packages in the UI? And perhaps how you're using upacks in general?

We added them as a way to introduce the format to new users, but didn't really anticipate it being used beyond that.

Thanks,
Alana

Hi @kc_2466 ,

We'll Add support for LC_TIME environment variable & user setting via PG-3054 in an upcoming maintenance release -- p[robably not this week's, but in the next or following.

Thanks,
Alana

Hi @carsten_1879 ,

We should have a build of BuildMaster 2025 later this week that you can try out that includes the new library. We'll let you know!

Thanks,
Alana