Posts made by jim.borden_4965

I'm attempting to be a good Proget citizen and migrate to Postgres ahead of the end of SQL Server support but I have a few concerns about the documentation around the process. There seems to be an expected understanding from the end user that volumes need to be set up for the database (if using docker like I am) to live in, but there is no mention of this in the migration wizard. I went through the whole thing and it happily told me I was done without creating any new volumes.

In that case, where does the data actually go? I assume it still goes to /var/proget/database in which case the next time I start a new container all the data will be gone. That will be quite a nasty surprise for someone who isn't familiar with this sort of thing.

So if that is the case, I think it needs to be mentioned in the migration wizard. I doubt there is a way to check if the volume has been mounted "properly" so I suppose if you can detect a docker environment you could show the extra pane regarding volumes.

The install docs for Linux actually already mention this, so that's all good, it just needs a place in the migration wizard.

This is a follow up to https://forums.inedo.com/post/13488 but I am wondering about the mentioned "API that would work across all package types" for package deletion. Is this feature still being planned for ProGet 2023?

What I'm after is a retention policy of "last X builds of each version" which doesn't seem possible with the current combinations and so one idea I had was to script the deletion from the outside using this REST API like I do now for NuGet (need to do it for maven too).

The other idea I had was making retentions rules have a scripting option (something like passing in the artifact ID and list of versions, and returning either a list of versions to keep or versions to delete, whichever is easier to implement) but that would be a new feature request that may not provide a lot of benefit for users other than us.

Thanks! Looking forward to that.

I am looking into repackaging and promoting from an internal Proget server to public nuget.org but in the process I cannot see a way to download the snupkg file. I see an option in the web UI called "download with symbols" but I'm wondering if that only applies to the legacy symbol format. I also tried using GET on the symbolpackage API that I noticed when uploading via nuget CLI, but that told me that the package ID was not specified or something. So is there a way to download the snupkg so that I can then reupload it to nuget.org ?

@atripp Thanks!

The docs indicate to start using the tag "latest" which is supposed to mean "give me the latest version" however as of the time of writing this post, it appears that latest points to 22.0.9 when 22.0.10 - 22.0.13 are available. Even the "22" and "22.0" tags continues to point to an older version. Is this by design, and if so what design?

According to this post, the class org.apache.maven.artifact.versioning.ComparableVersion is the source of truth for how maven verisons are sorted, but ProGet maven feeds don't seem to follow this. For example, given the versions 3.1.0-9 and 3.1.0-10, the class will sort them numerically so they are in the order provided just now. ProGet, on the other hand, sorts them lexographically and considers 3.1.0-9 higher than 3.1.0-10. There are probably other weird quirks as well but this is the one that I am concerned with. The retention rules for "keep X latest versions" will delete the wrong artifacts because of this.

This is what I used to prove the above:

import java.util.Arrays;
import org.apache.maven.artifact.versioning.ComparableVersion;

public class App 
{
    private static final ComparableVersion[] VERSIONS = new ComparableVersion[]{
        new ComparableVersion("3.1.0-10"),
        new ComparableVersion("3.1.0-9")
    };

    public static void main( String[] args )
    {
        Arrays.sort(VERSIONS);
        for (ComparableVersion v : VERSIONS) {
            System.out.println(v);
        }
    }
}

The resulting output is

3.1.0-9
3.1.0-10

Gosh sorry, I actually forgot to copy the new backup before trying again so the result is that the second variant of these backup and restore do not work (I took these from an older version of the documentation) but the first variants do (these are in the current docs)

I have been using proget for quite a while and it's overdue for an upgrade due to various bugs that have been fixed in newer versions, and while I'm at it I would like to upgrade to MSSQL database instance from 2017 to 2022. My thought process is that this would be:

1. Start new MSSQL docker instance
2. Backup current MSSQL docker instance
3. Start new proget docker instance pointed at the new database

However, I find when I do this the docker feed has vanished according to the newly spun up proget instance. Is there a step I am missing. This is the command I used to backup from MSSQL 2017:

(I tried both of the following):

docker exec -it proget-sql /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q "BACKUP DATABASE [ProGet] TO DISK = N'/var/opt/mssql/backup/backup.bak' WITH FORMAT"
docker exec -it proget-sql /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q "BACKUP DATABASE [ProGet] TO DISK = N'/var/opt/mssql/backup/backup.bak' WITH NOFORMAT, NOINIT, NAME = 'ProGet-full', SKIP, NOREWIND, NOUNLOAD, STATS = 10"

Then after copying out of docker and into the new docker instance, I restore the new instance:

(I tried both of the following)
docker exec -it proget-sql-2022 /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q 'RESTORE DATABASE ProGet FROM DISK = "/var/opt/mssql/backup/backup.bak" WITH FILE = 1, NOUNLOAD, STATS = 10'
docker exec -it proget-sql-2022 /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q 'RESTORE DATABASE ProGet FROM DISK = "/var/opt/mssql/backup/backup.bak" WITH MOVE "ProGet" TO "/var/opt/mssql/data/ProGet.mdf", MOVE "ProGet_log" TO "/var/opt/mssql/data/ProGet_log.ldf"'

Either way, the docker feed is missing when the new instance is spun up. Is there any way to resolve this?

Oh, if you meant an example with embedded icon, .NET official packages do this too:

https://www.nuget.org/packages/System.Collections.Immutable/7.0.0-rc.1.22426.10

Sorry I didn't notice this reply! Sure, our published packages have used embedded licenses for several versions now. Here is one -> https://www.nuget.org/api/v2/package/Couchbase.Lite/3.0.2 and here is a link to how the server shows it https://www.nuget.org/packages/Couchbase.Lite/3.0.2/License

I am using a nupkg that has an icon entry instead of iconUrl (the latter being deprecated) but this causes ProGet to omit the icon information. I suspect the correct thing to do is to put in an iconUrl with a link to the file on the proget server (similar to what happens with an embedded license). I don't have any packages released on nuget to compare the icon situation but here is what I noticed regarding both LICENSE.txt and the icon.

On nuget (a package using embedded license, but iconUrl) using https://api.nuget.org/v3/registration5-gz-semver2/<package>/index.json:

X means "arbitrary index" since it won't be meaningful in this context
items[X].catalogEntry.iconUrl: https://api.nuget.org/v3-flatcontainer/<package>/<version>/icon
items[X].catalogEntry.licenseUrl: https://www.nuget.org/packages/<package>/<version>/license

On proget (a package using embedded license and icon) for the same keys:
items[X].catalogEntry.iconUrl does not exist
items[X].catalogEntry.licenseUrl: https://aka.ms/deprecateLicenseUrl
items[X].catalogEntry.licenseExpression: package://<package>/<version>/LICENSE.txt

I also see the nuget client asking ProGet for [url]/v3-flatcontainer/<package>/<version>/license to which is responds 404 OData method not implemented, suggesting that it might be baked into the protocol somehow? I don't see a reference to that URL in the index.json. My conclusion is that iconUrl and licenseUrl should be present in this scenario and should point to proget endpoints that serve the content.

I understand the lack of motivation for our case, certainly. An API that works across all packages types would probably be even better than a maven specific one. On one final side note, though, is it normal for the delete button in the UI to leave the actual backing files intact? I am noticing that is what happens. The entry disappears from the feed but the files are left on the system.

To add a bit more detail, we are basically trying to do our own retention with the free version where actual retention rules are not available. This is easy enough with NuGet, and I have a script that keeps things tidy. We are hosting CI builds inside and we don't need the entire history of the world inside. Same with maven. I have gotten to the point of being able to enumerate package versions with maven via its metadata, but there is simply no programmatic way to delete them it seems (despite the UI allowing it).

Can anyone confirm that this works for maven packages? I'm going insane trying to figure out how to delete maven packages programatically like I can with NuGet. DELETE requests are outright rejected with the following message:

Only GET, HEAD, and PUT are supported for this URL.

Is there any way to delete a maven package without going through one by one the entries in all feeds and clicking on delete artifact, then confirming YES?