Posts made by atripp

My bad, can you try this instead? Basically we are trying to delete all "R, M, T" executions except the most recent 1000 of each type.

This is what the code is doing now, just really inefficiently for some reason -- and the inefficiency seems to have caused a "backlog" of sorts.

USE [BuildMaster]

BEGIN TRANSACTION

DELETE [Executions]
  FROM [Executions] E,
     (SELECT [Execution_Id], 
             ROW_NUMBER() OVER(PARTITION BY [ExecutionMode_Code] ORDER BY [Execution_Id] DESC) [Row]
       FROM [Executions]
      WHERE [ExecutionMode_Code] IN ('R', 'M', 'T')) EE
WHERE E.[Execution_Id] = EE.[Execution_Id]
  AND EE.[Row] > 1000

SELECT [ExecutionMode_Code], COUNT(*) FROM [Executions] GROUP BY [ExecutionMode_Code]

ROLLBACK

Hello;

We haven't seen this error in quite a long time, and I remember it was something we had addressed ages ago. Internally, we still jokingly call it NT AUTORIDAD from this experience, because who would have guessed they localized those names...

That said, we didn't really change the installation process for Otter 3.0, and it's really just a copy/paste of the ProGet and BuildMaster installation scripts. I don't know why we wouldn't have heard from it until now.

It's possible this solution was never brought over to the Inedo Hub? Maybe.. for now, we'd rather not mess with the installation scripts until we get more reports, so we'll just wait to hear more. If anyone else experiences this , in any products, please share it :)

Alana

Thanks @viceice !!

I think we're really close, actually. You're right, the service code (copied below), sets the version, so this wouldn't work anyways.

However, I think if we just write-out a script at build time that does something like EXEC Configuration_SetValue 'Internal.DbSchemaVersion', $VersionNumber... and then incluse that in SqlScripts.zip`, it would always work.

Ultimately what I'd love to do is build a guide like the Docker Compose Installation Guide, but have it be the Kubernetes Installation Guide.

If we get the version-number-setter script included in SqlScripts.zip, how close do you think we'll be to a Kubernetes install guide? Would it basically be the same as that Compose guide, but just have k8-commands and k8-sample code instead?

        private static int UpdateDatabaseSchema()
        {
            Console.WriteLine($"ProGet version is {typeof(Program).Assembly.GetName().Version}.");
            var currentVersion = getCurrentVersion();
            Console.WriteLine($"Current DB schema version is {currentVersion?.ToString() ?? "unknown"}.");
            if (currentVersion == typeof(Program).Assembly.GetName().Version)
                return 0;

            using (var p = Process.Start(getStartInfo()))
            {
                p.WaitForExit();

                if (p.ExitCode == 0)
                    setCurrentVersion();

                return p.ExitCode;
            }

            static ProcessStartInfo getStartInfo()
            {
#if NET452
                return new()
                {
                    FileName = "mono",
                    Arguments = $"/usr/local/proget/db/inedosql.exe update /usr/local/proget/db/SqlScripts.zip --connection-string=\"{SharedConfig.ConnectionString}\""
                };
#else
                return new()
                {
                    FileName = "/usr/local/proget/db/inedosql",
                    ArgumentList =
                    {
                        "update",
                        "/usr/local/proget/db/SqlScripts.zip",
                        $"--connection-string={SharedConfig.ConnectionString}"
                    }
                };
#endif
            }

            static Version getCurrentVersion()
            {
                try
                {
                    var s = DB.Configuration_GetValue("Internal.DbSchemaVersion")?.Value_Text;
                    Version.TryParse(s, out var v);
                    return v;
                }
                catch
                {
                    return null;
                }
            }

            static void setCurrentVersion()
            {
                try
                {
                    DB.Configuration_SetValue("Internal.DbSchemaVersion", typeof(Program).Assembly.GetName().Version.ToString());
                }
                catch
                {
                }
            }
        }

Thanks Philippe!! That's helpful.

Can you try this sql?

USE [BuildMaster]

BEGIN TRANSACTION

DELETE [Executions]
 WHERE [ExecutionMode_Code] IN ('R', 'M', 'T')
   AND ROW_NUMBER() OVER(PARTITION BY [ExecutionMode_Code] ORDER BY [Execution_Id] DESC) > 1000

SELECT [ExecutionMode_Code], COUNT(*) FROM [Executions] GROUP BY [ExecutionMode_Code]

ROLLBACK

You should then see results like this:

R 1000
M 1000
S 1560
T 377
B 999

You can further inspect the tables, but this should do the trick. If the results look okay, then please run only the DELETE statement and then it will be fine.

Can you let me know if it works? we will incorporate this logic in BM-3659

Hello; thanks for reporting the bug! This was a UI regression, and the HostName field was not being dispayed on the edit form. So it's already fixed in code (via OT-384), and we'll get a new release out quite soon, perhaps a day or so

Thanks,
Alana

Hey @philippe-camelio_3885

You may be looking at the wrong database... based on Otter in your query.

Here's a way to see executions by execution type: SELECT [ExecutionMode_Code], COUNT(*) FROM [BuildMaster]..[Executions] GROUP BY [ExecutionMode_Code]

As for retention policies, you should be able to see the logs of those., and see what's being purged.

Anwyays, w'ell figure it out... hang tight!

Hi @viceice , we don't have an Official kubernetes deployment for ProGet yet, but working with the community on figuring out how to deploy this way is how we get there. eventually we'd like to offer ProGet Enterprise via Kubernetes and enable load balancing, etc.

I'm not so familiar with Docker or Kubernetes to be honest, but I can answer all of questions so we can figure it together.

Is there any ways to run the proget docker image to only upgade the database and then exit?

Not that I can think of. Here's how it works behind the scenes:

• On ProGet (for Windows), the database is initialized/upgraded at install time using a tool called inedosql: https://docs.inedo.com/docs/proget/installation/installation-guide/manual#database

• On ProGet for Linux, the ProGet Service is responsible for upgrading the database on startup using the same mechanism (i.e. inedosql). This was done to simplify the Dockerfile.

I'm not sure what an InitContainer is, but based on the name, I guess it's a container that exists only to initialize a cluster? Technically we could do several things:

• run inedosql on Linux
• add a commandline argument to the ProGet service to terminate after doing a database upgrade

I don't know what would be easier, or better. What do you think?

Git-based Rafts are part of the Git extension, so if you're not seeing them when creating a new Raft (or they've disappeared), then there is probably an extension load error.

Do you see Git under Admin > Extensions?

We can definitely try to diagnose what's going on. What are the types of Executions in that table? Manual? Build? Etc?

Hello; you should see a checkbox, like this.

However, due to a bug (now fixed via PG-1885) the checkbox wasn't being displayed due to a license validation problem.

It will be fixed in the next maintence release, scheduled for later today

Hello, great question!

I hope that I can answer your question by showing you what I changed in the documentation

Feed usage controls which tabs and messages are displayed in the user interface. For example, "Private/Internal packages" won't display the license filtering options, as you wouldn't create license usage restrictions for your own packages.

Note that not all feeds have all of these Feed Usage options. Generally speaking, we don't recommend using mixed packages, as it will present all of the user interface options; most of them won't be relevant for packages you create (like license filtering or vulnerability scanning).

I'm not so familiar with ClickOnce publish targets, but my understanding is that ClickOnce is deployed to an ordinary web-based file directory, like a site in IIS that has "file browsing" enabled or something?

IF so, then I think Asset Directory would work. That's kind of like that, and is meant for general files. Feeds require a special API to access.

Let us know how it goes.

Hello; I'm not sure if we can help here, this sounds like something more appropriate for Azure DevOps community.

Hello;

This is apparently a default limitation in .NET5/Core; I'm not sure if it can be changed outside of the code, but I've logged a product change PG-1876 to get this fixed in the next maintence release.

Cheers,
Alana

@andrew_5903 thanks, I'd like to update the docs! Did you end up writing a script to just call that for each Jar+Pom in your directory?

Typically these are cleaned up via retention policies... but where is the DELETE [Executions] WHERE [Execution_Id] = @Execution_Id being called?

Hello; we haven't forgotten about this, just haven't had an opportunity prioritize with everything else. Hopefully we'll hear from some other users who are seeking similar functionality

Hi Andrew,

The only way to get a Maven artifact in ProGet is by using the API to push it. The re-indexing can detect missing files on disk, but it does not add new files.

This is by design, we simply never created this functionality for ProGet. Even in old versions.

We may add it later, but there's not a lot of demand, since it's "relatively easy" to write a script to import everything in via the API. Really it's just doing a number of HTTP Push commands by starting wtih the POM files as i mentioned.

Cheers,
Alana

Hello;

As of ProGet 5.3.17, ProGet does not support drop paths for Maven; the precise reason is complex, but it's ultimately a result of the way Maven is structured (i.e. a file system vs packages), and how files can be added piece-meal.

It is something we are considering adding in a future release, but it's complex. Other users have reported that they've used a process like this for a disk-based repository.

1. Traverse all directories and upload all POM files with a path relative to the root
2. Traverse all directories again, and upload all non-POM and non-checksum files (like .md5)

There will be errors, particularly if you have invalid POM files or your directory structure doesn't match the required MAVEN convention, so inspect those case-by-case to determine if it matters (like an bad artifact from 5 years ago can probably be ignored).

Unfortunately we don't have a lot more details, but we'd love to hear more from your experience if you end up scripting this,

Cheers,
Alana

Hi Philippe,

I don't think there's anything in particular that would have changed that would cause this slowness.

Those tables are big, and I would definitely recommend purging old data from them.

In any case, the problem is likely index fragmentation. Deleting an execution will cascade to those tables, so I'm thinking there might be some kind of indexing fragmentation or problem.

Here's some information about how to detect and repair index fragmentation: https://inedo.com/support/kb/1167/sql-server-recommendations

Can you try that, and see if it helps?

Thanks, Alana

ProGet does not support package-level permissions; you would need to create separate feeds, or create a custom package filter (in C#) that could have some sort of filtering logic per user.

Hi @Crimrose, this would probably be better to check on the Chocolatey forums / community site. But if you can find the answer, please share it :)

Thanks; I can confirm that there indeed is an error parsing one of the PDBs in the file you sent, which is why it won't index on upload. It could be just that particular package or file, though. I wonder if you try different packages, it might work.

Otherwise, not sure why/how it would work from the service though...

Anyways we'll investigate this further, but it might take several days to schedule the time, since this is quite complex, binary/bit-level parsing logic, and might be complex.

Hello; the files should definitely be indexed on upload...

Could you share the package you created created, so that we could evaluate/test to see if we can reproduce the problem? I'm not sure if you can attach to the forums, but you could also email it to support at inedo dot com ... please add [QA-475] in the subject so we can easily find it.

Hello; due to the complexity of handing the apt signing, connectors to other apt repositories are not supported for Debian Feeds in ProGet at this time; we didn't anticipate this being a common usecase.

You could, however, publish .deb packages you've downloaded to the repository manually.

hi Simon,

The default connection pool size for .NET's SQL Server connection is 100, so that behavior wouldn't be unexpected if there were a lot of requests to ProGet (very common in a package restore) and the database driver wasn't responding fast enough for whatever reason (also very common... too many network requests coming in, too many network requests going out, slow database server, etc.).

The .NET Runtime will eventually close those connections, and they will then be terminated by the TCP stack shortly after (minutes?).

Alana

Hi Simon, I'm guessing there's a 500 error being thrown at the same time? Or, perhaps, it's a permission error? In any case, can you try to get a feeling for the underlying error message? That will help debug it.

Hi Peter,

Thanks for reposting this; this error is basically what you can expect from a "network stack" being overloaded; each request to a ProGet feed can potentially open another requests to each connector configured (maybe NuGet.org, maybe others), and if you are doing a lot of requests at once, you'll get a lot of network activity queuing up. SQL Server also running on the network, so those just get added to the queue, and eventually you run out of connection.

Do you have a lot of containers running on the same computer that ProGet is running on? If so, that coudl also contribute to the network stack being overloaded.

The best way to solve is with more hardware, or by removing connectors to nuget.org, etc.

Also note that users can overload a server as well, and this is why load balancing will be very important if you want to keep reliability; See How to Prevent Server Overload in ProGet to learn more.

Hi @p-bruch_5023 can you post this to a Topic? It'll be a lot easier to track internally, and for other users to find since it's newer and different cases than other timeouts.

Hi Simon, based on what I'm seeing, it looks like the InedoCore extension didn't load, which is what would happen in this case...

Can you try restart container?

On the Admin > Extensions> What do you see on the InedoCore page? There should be a list of extensible components presented, including the directory type...

These days, there are very few packages with quicks like this, so we recommend just repackaging (either using the feature, or manually) a local copy for caching purposes.

Owin is one of these packages unfortunately. The latest (and only) package version is 1.0 (in some cases) and 1.0.0 in others. It's also over 8 years old, so it can't be helped.

ProGet 5.2 had better support for these versions quirks using a feature called "Legacy (Quirks) Feeds", but those feeds couldn't handle SemVer queries properly, since requests like 1.0 were ambiguous (should it return 1.0 or 1.0.0, both of which are valid versions, etc), so it was a big tradeoff. They were fully removed in ProGet 5.3.

You can basically ignore this error.

When you press the Save button on the All Settings page, it triggers a Restart of the Application Pool after saving. Most of the time this is not noticed at all, but sometimes it happens -- and this might happen. It goes away within seconds if you hit refresh.

Hello;

Long story short, the problem is that your package's nuspec file has an invalid version number (1.0); if you edit the file, and put in a proper SemVer, it will be fine. This is what repackaging does, by the way. It creates a new package with a different version number.

This is a long-standing versioning quirk with NuGet that still comes up every now and then; in the old days, you could have packages like 1.0 and 1.0.00 or even 1.000.0, and they'd all be different.

NuGet dropped support for this over five years ago, but since old packages with quirk versions remain, they did all sorts of strange work-arounds in the NuGet client. For example, you may see a file request for 1.0.0, and then 1.0.0.0, then 1 then 1.0.

This is because the NuGet API only shows a three-part SemVer anymore, but the files are still accessed by their original version number. ProGet does not do the "version dance" to find the real package file, which is why you get these errors.

We eventually dropped most support for this versioning, and basically you can just have "some" quick packages in feeds, but they won't work through connectors in most cases.

Hi @scroak_6473 good to know! So, I've added the WORKDIR /usr/local/proget/ line right above our CMD line, and it should go in the next release.

Hello;

Tags in Docker registries are really just a human-readable pointer to a digest (hash) of an container image. It's really just a name+digest, and there's no additional metadata provided by the Docker API.

This is why we encourage Semantic Versioning for Containers, and have a feature built-in that helps with this. You can then reliably parse those tags like semnatic version numbers, and use them as needed.

The Packages vs Containers documentation also talks about some of the quirks, if you're not familiar with them already.

Hi Sri,

At first, you can just replace the license key (Admin > License Key) to change the edition of the software (From Express to Enterprise). There's no need to migrate from one server to another.

However, if you want to migrate from one server to another for a different reason, then there are two general approaches:

• application-by-application (this involves using the import/export feature), and is ideal for when you only want to migrate limited, application-specific data
• full migration of all data, using the back-up / restore instructions

The Backing Up BuildMaster instructions detail this, but basically you just need to have three things:

• BuildMaster Database; a SQL Server database that contains all of BuildMaster's configuration data
• Encryption key; to encrypt/decrypt sensitive data in the database (like credentials); this is stored in the shared configuration file
• Artifact Library Files; the path on disk (defined in Artifacts.BasePath setting) that contains all the files for artifacts you created within BuildMaster

Hope that helps,
Alana

I don't have a detailed timeline with Otter 3.0, the scope appears to continue to creep (but, perhaps in a good way ). But it's still looking on track for early next year.

Probably the best thing to do is to get in touch with our sales engineering team, so we can learn a bit more about what problems you're trying to solve, and can give some more details about how Otter 3.0 will help; they can at least show you what's upcoming, so you can better decide if it's a good fit.

Hello, thank you for helping to identify this issue, and how we can solve it.

Just so I can understand the situation, I want to confirm that setting the WORKDIR will allow ProGet to run on CentOS7?

If so, do you think editing our Dockerfile like below (see the line I added) will fix the issue? It seems something easy we can try in the next release then.

FROM mcr.microsoft.com/dotnet/aspnet:5.0.0

EXPOSE 80

COPY proget/ /usr/local/proget/

****** ADD THIS LINE ****
WORKDIR /usr/local/proget/
****** / ADD THIS LINE ****

ENV SQL_CONNECTION_STRING "Data Source=proget-sql; Initial Catalog=ProGet; User Id=sa; Password=;"
ENV PROGET_SVC_MODE both

VOLUME /var/proget/packages
VOLUME /var/proget/extensions
VOLUME /usr/share/Inedo/SharedConfig

CMD ([ -f /usr/share/Inedo/SharedConfig/ProGet.config ] || echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig><ConnectionString Type="SqlServer">'"`$SQL_CONNECTION_STRING"'</ConnectionString><WebServer Enabled="true" Urls="http://*:80/"/></InedoAppConfig>' > /usr/share/Inedo/SharedConfig/ProGet.config) \
&& exec /usr/local/proget/service/ProGet.Service run --mode=`$PROGET_SVC_MODE --linuxContainer

Thanks, pleas let me know

Unfortunately, when symbol serving doesn't work, it can be a pain to diagnose...

Can you "start from scratch", documenting your steps along the way, so that I can try to reproduce exactly what you're doing?

Start by making a very simple, hello world sort of library (maybe one class, with some basic code you can easily step/through and debug).

After that, then create some brand new feed (it sounds like you want two feeds? a symbols and a package feed?), then configure the new feed in Visual Studio. Then follow the other steps, like seeing if you can find the symbols in Visual Studios, etc.

If you can share the exact steps you did, and the package you upload, then I can reproduce the error you're seeing by following steps using the package.

Hello; please restart the ProGet service. This will cancel all executions upon restart.

The legacy pdb format bundles sources in the NuGet package (in which case, it comes from ProGet), whereas pdb file uses source link.

So it depends on the format you make the pdb. It sounds like it's the new format, however.

Sorry, wrong software - please see our friends at otter.ai for transcription. We do server automation.

Cheers

In fact, we're working on this project now :)

It's going to be available in Otter 3.0, which will be released in the coming weeks. And even better, you can run Otter 3.0 on Linux/containers :)

NuGet/VS will aggressively cache packages, so if you're not seeing the "Symbol Load Information" it probably means you have an old, cached package or DLL. It's hard to get-around this, so it's best to really just create new package versions so the caching isn't happen

Symbol serving can be pretty tricky to get working, so make sure to follow the troubleshooting steps in the documentation.

You'll see SymbolLoad information for your DLL, which should look something like this:

If you're not seeing a call to your ProGet server, then Visual STudio isn't configured as needed.

If ProGet is returning a 404, then the symbol isn't indexed. You you see the status of symbols that ProGet found on the "Symbols" tab of your package.

@philippe-camelio_3885 FYI, we will add a checkbox for auto-purging soon, BM-3655

Hi @sbolisetty_3792 , just to let you know, this will be fixed in the next maintence release of BuildMaster (BM-3654). Basically, if a Server has a Single environment, then that environment will be used for credential resolution.

HOWEVER, note that this won't work for your dev-cap server because it's in two environments. So in that case, you couldn't use an environment-specific credential.

Hello, the configuration plans can do a ton of great things, but they're a bit confusing -- and a big thing we want to be improving in the next year, with both software and documentation changes.

But I'll explain a couple things you might already know, for the sake of helping someone who might read this in future. Using your first script (without the execution policy):

• The OtterScript is executed twice in a row; first in "Collect" mode then "Ensure" mode if it
• Ensure-File always executes in Collect (and it records whether the file exists), and it may execute in the "Ensure" run (where it would create/overwrite) if it reported drift
• Start-Service never executes in Collect, but may run in "Ensure" mode... but may executes if another operation in the block reported drift (i.e. if Ensure-File reported drift)
• Post-Http never executes in Collect mode, and it never executes or Ensure modes, because it's the only statement in a block

The with executionPolicy=always policy changes this, and it's the intended use of this execution directive. But... it's an editor bug, so we'll fix it.

So... all that said... I don't think I'd recommend doing an error handling in a Configuration plan like this; it feels more appropriate for an Orchestration plan that you run for a purpose, to like provision or set-up a server.

Otter will perform a routine configuration scan at least every hour, so there's a good chance this will just end up sending the same error message over and over:

1. Drift is a detected
2. Configuration FAILS to change
3. Error notice is sent

This isn't all that helpful, and is more of an indication of an outage more than anything else. And this isn't a great way to detect an outage. Instead, you can check the status of the server; if there is a failure during a Configuration execution, the server status becomes Error, and it can then be investigated about the details.

Hi there, I'm afraid the documentation is incorrect

There is no such way to do that in the current version, so for the time being all users will have full access.

However, the next version of Otter is in the works, and it's going to be great; not only will it run as as a container on Linux, but we're making a lot of UI improvements so that you can do things like run PowerShell / Shell directly as a job.

We'll be bringing over things from BuildMaster as well, like the combined script page, Job Template Variables - and also the pseduo-users like Anonymous, Authenticated, and Everyone.

You will then be able to add/restrict users just like BuildMaster, though all users will still be full admins.