@jimbobmcgee fantastic, we'll review/merge soon! thanks much :)

Hi @scusson_9923 ,

This seems to be an issue related to release vs debug builds (works fine locally, but not when deplyoed to server), and we'll investigate and fix via OT-517 in an upcoming maintenance release (2024.4) - not sure on the exact schedule, but we're targeting the next couple weeks

-- Dean

@jimbobmcgee thanks; we'll definitely investigate this later, but it will likely not be for a few months until we can do some "heads down" time with this stuff

Honestly I don't remember how any of this works, so I could be wrong and you need to do something else. It's clearly not something we document.

Our primary use case is more like this, uploading basic scripts:
https://docs.inedo.com/docs/otter/scripting-in-otter/otter-scripting-powershell

@jimbobmcgee thanks for reposting this here as well!

PSEval is definitely not meant for scripts like that, due to how the parsing works... but as you noticed, the $PSEval($ps) should work. We probably won't change this.

PSExec (i.e. Execute-Powershell) can capture variables, but not output streams. So something like this:

set $hello = world;
$PSExec >>
  $hello = 'dears';
>>;
Log-Information Hello $hello;

Similar to my comments on the PSEval thread, this is another one of those rabbitholes that can break stuff, since the existing behavior seems to work for some users. So we're super-cautious about it.

It's likely we won't change these behaviors as they are "good enough" for the intended usecase of Otter.

@jimbobmcgee that's a nice idea; we'd definitely be open to a pull request on those FYI

Based on other list/map functions I think it'd be relatively straight-forward and an easy pattern to follow:
https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/VariableFunctions/Lists/ListRemoveVariableFunction.cs

Just not something we can focus on now though

@jimbobmcgee thanks for reposting this here as well

Working with PowerShell output variables is a very long-standing challenge, in particular because PowerShell has very inconsistent returns based on Windows, Windows Core, LinuxCore. We made some fixes not too long ago, but it's still not perfect and was a ton of effort that ended up breaking some user scripts.

And as you probably saw poking around the execution engine code, a variable prefix ($, @, %) is more of a convenience/convention, and the prefix isn't really available in any useful context. I'm almost certain you can do stuff like $MyVar = @(1,2,3) for example. This is very likely not something we will want to change.

Keep in mind that OtterScript was never designed as a general-purpose scripting language, but as a light-weight orchestration script to run other scripts. So these limitations happen.

I will make a note of this on our long-term roadmap, but it's likely we won't take action on it due to sensitivity of all this and not wanting to break existing scripts.

@jimbobmcgee thanks for reposting this here

This is a long-standing behavior of Otter/OtterScript and it's most likely not a trivial fix and would involve updating the parser/execution engine (after remembering how it all works) - so not something we'll do in a maintenance release for a community/free user, as I'm sure you'll understand

However now that it's here, I will link it to our internal roadmap planning and consdieration for Otter 2025.

Hi @james-woods_8996,

Each instance of ProGet needs its own file storage (S3 bucket, disk, etc). You definitely do not want to use the same storage across instances - that'd cause a major issue.

Some users have been tempted to use a combination of Database Replication + Disk Replication with third-party "external" replication tools, and learned the hard way that it's an absolute disaster once deployed. So don't try that :)

Basically the "external" (non ProGet) replication is way too slow to handle the type of traffic ProGet receives, and the files/database replication cycles are never in sync.

-- Dean

Hi @cooperje_6513 ,

It sounds like you had done some manually/IIS configuration, or perhaps an error occurred at some point. In any case, I would manually remove all components (service, IIS, etc), and you can delete any registered installation in the c:\ProgramData\upack folder. Just keep your installed package files (typically c:\ProgramData\ProGet).

Then, just install fresh, pointing to the same database. Use the Integratred Web SErver, not IIS. That's what we recommend now.

NOTE that the WebApp folder is no longer used.

Hi @kc_2466 , we'll get this one fixed via PG-2885 in the next maintenance release!

@jimbobmcgee thanks for the detailed analysis! This is on my list, but haven't had time to properly reproduce and test this.... but as you noted, the code fix looks so easy.

I just made a quick change (OT-513) and prerelease (2024.2-rc.1). Can you give it a shot?

https://docs.inedo.com/docs/installation/windows/howto-install-prerelease-product-versions

Hi @ghollosy_9163,

I'm afraid this will not be an easy problem to troubleshoot; there were some major changes in ProGet 5.3 with regards to Docker feeds, so it's possible that there was a data migration problem during the upgrade process.

Ultimately it looks like your container configuration files aren't there. I don't know why, but I'll try to point you to where/how they are stored.

Docker blobs are stored on disk, and you'll see files named by their hash. Based your screenshot, it'd be a file like bf3c18259..... These files are also indexed in the database, in the DockerBlobs table.

If the files aren't anywhere on disk, then check backups. It's possible they got accidently deleted, and you can just add them back.

If the files are missing on disk, then they are probably gone for ever. If they are not in the database, then perhaps something happened during the migration? I really don't know. It's possible to insert them in the database, but we don't have an automatic way to do this - basically you'd need to write a script.

-- Dean

hi @jaehyung-shin_8059 ,

If you click on the latest tag, do you see any information about the packages in the container?

Container images are scanned on upload if they are small or queued to be scanned in the background if they are large. There are sometimes errors scanning containers, and if so, these errors will be logged... typically under Admin > Executions.

-- Dean

Hi @jaehyung-shin_8059 ,

From what you described, it sounds like you'd like to have a single tag (like :v3) resolve to different architectures?

This is called a multi-platform image, and you'll need to study/follow the Docker guidance on how to create one: https://docs.docker.com/build/building/multi-platform/

Long story short, this is not something that you can do by simply pushing two images to the same tag like you're doing; it's quite a bit more complex, and you have to build the images in a very specific manner.

But once you do that, ProGet does indeed support them (they are called "fat manifests") and you will see a note/warning when viewing an image for one.

-- Dean

@parthu-reddy yes, but we do recommend migrating...

There are some known bugs/quirks with Maven (Classic) feeds and we will not fix them.

We will likely not migrate them to PostgresSQL, which means you won't be able to migrate to PostgreSQL in ProGet 2025+.

So it's likely that ProGet 2027 will not support them.

Hi @parthu-reddy ,

Huh... that's interesting... but not surprising. The Maven (New) feeds assume POM files are valid XML, but I guess Marvin supports invalid XML for POM files

I fixed this via PG-2859 which add Add Support for Invalid POM files on Maven (New) Feeds. You can access it via 2024.23-rc.1 on the prerelease feed (InedoHub), or the 24.0.23-rc.1 Docker image.

Hopefully this will work-around these migration issues.

-- Dean

Hi @parthu-reddy ,

This error means that the previously listed pom file (ant-1.6.5.pom) is somehow corrupted. It cannot be loaded as XML due to the error.

I assume it's this artifact:
https://repo1.maven.org/maven2/ant/ant/1.6.5/

That one is fine at the source. I would just remove it from your old/classic feed, since I assume it's just something from maven central. And it can then be downloaded again.

-- Dean

Hi @parthu-reddy,

For a major upgrade, we recommend to schedule a maintenance window and then stop traffic from the load balancer. Then, upgrade the servers.

For a maintenance release, it's fine to just upgrade them one at a time. It only take as few minutes to do that. There may be a few errors with the database/code being out of sync, but it likely will not cause any problems.

-- Dean

@parthu-reddy this is a somewhat expected error, and it's something we'll improve in a future version of ProGet, but in all a cases it will cause some kind of problem.

The problem is that you added a new feed/connector (in this case, a Maven (New)) that is unknown to previous versions of ProGet. So when you try to load that unknown type in older versions of ProGet, you get this error.

If you deleted the connector before downgrading, it would have worked. So, I would upgrade, delete, then you can downgrade again.

-- Dean

@sneh-patel_0294 I don't think so, its only displayed on that page...