@dean-houston said in PSEval can be called as $PSEval, @PSEval or %PSEval, but null/empty returns only make sense for $PSEval: 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. For what it is worth, if this is the intent, then it does not match what actually occurs. The execution engine throws exceptions when you mismatch the variable types: # mixed sigils { set $ok = ""; set $no = ""; try { set $a = "blah"; set $ok = $ok: scalar; } catch { set $no = $no: scalar; force normal; } try { set $b = @(1,2,3); set $ok = $ok: vector-as-scalar; } catch { set $no = $no: vector-as-scalar; force normal; } try { set $c = %(a: 1, b: 2); set $ok = $ok: map-as-scalar; } catch { set $no = $no: map-as-scalar; force normal; } try { set @d = "blah"; set $ok = $ok: scalar-as-vector; } catch { set $no = $no: scalar-as-vector; force normal; } try { set @e = @(1,2,3); set $ok = $ok: vector; } catch { set $no = $no: vector; force normal; } try { set @f = %(a: 1, b: 2); set $ok = $ok: map-as-vector; } catch { set $no = $no: map-as-vector; force normal; } try { set %g = "blah"; set $ok = $ok: scalar-as-map; } catch { set $no = $no: scalar-as-map; force normal; } try { set %h = @(1,2,3); set $ok = $ok: vector-as-map; } catch { set $no = $no: vector-as-map; force normal; } try { set %i = %(a: 1, b: 2); set $ok = $ok: map; } catch { set $no = $no: map; force normal; } Log-Information Mixed sigils: success${ok}, fail${no}; } DEBUG: Beginning execution run... ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Vector value to a Scalar variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Map value to a Scalar variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Scalar value to a Vector variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Map value to a Vector variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Scalar value to a Map variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Vector value to a Map variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() INFO : Mixed sigils: success: scalar: vector: map, fail: vector-as-scalar: map-as-scalar: scalar-as-vector: map-as-vector: scalar-as-map: vector-as-map There are also syntax elements which require specific context, such as foreach requiring a @vec (Iteration source must be a vector value). I can certainly understand why you would not want to update the base classes so they provide the context (scalar, vector, map) to implementations but I expect it is probably the safest solution for maintaining backwards compatibility with existing authored scripts (if that information is available to you at parse-time). The alternative is to let the script author pass it along as an optional property to $PSEval() (similar to $GetVariableValue()), but this introduces another character which would then need to be escaped within the embedded Powershell (i.e. ,), and that probably would break authored scripts.

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

Hi, thanks for reporting this! I've reproduced it and we'll have a fix in ProGet 2024.26, which is scheduled for release on Friday.

@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

Hi @kc_2466, Thanks for submitting this to us. It looks like there is an issue with packages with 3 or less characters that may fail to download. I created ticket, PG-2886, which will release this Friday (February 3rd, 2025), that will contain the fix for this. I also want to note that version 2.8.0 of syn does not exist on crates.io, so I verified using syn 2.0.8. Thanks, Rich

Hi @arose_5538 , Looks like this was indeed a regression in 2024.23 as a result of upgrading the JSON library we were using... I guess it's a lot more strict. Of course, upack is also wrong, but for whatever reason it worked before. anyway it's an easy fix, and will be fixed in the next maintenance release (scheduled Feb 7) of ProGet via PG-2884. In the meantime, you can just downgrade to 2024.22. And I checked pgutil 2.1.0 will be released soon :) Cheers, Alana

@steviecoaster great news, glad you got it all working

Hi @kc_2466, Looks like download uses an API we haven't implemented. Didn't expect that it would use a different mechanism from install! I don't think we'll get a fix for this in tomorrow's release, but I'll schedule it for the following on Feb. 7 (should be v2024.26). Thanks!

@jimbobmcgee that's too bad it didn't work :( That's probably why we didn't update the page in Otter 2024 to work with those types from BuildMaster... and as you saw from the code, it's probably not trivial. I know that some of the other platform modernization efforts (especially with HTTP/S support) took a lot longer. I guess the only option for now is to just add a list of server names. This is still on our roadmap, but rewriting the page is more than we can do in a scope of a fix like this.

Hi @atripp , Thank you for your quick reply. We will try your suggested approach and migrate from OSS Index to ProGet's Vulnerability Database. We will also update our server installation. There are other libraries with the same issue, so your statement regarding the reliability of OSS Index as a data source seems to be accurate. Best regards

after upgrading to the latest version , we ran into the same problem and had to revert back to an earlier version . we are looking forward for the fix aswell

@lisama7982_5385 this would require using the Docker API, which is kind off a pain, but if you search for things like "how to tag an image with a digest usng Docker API" or something you should find it eventually You can also use the Docker CLI by doing something like docker pull using the digest, then docker tag, then docker push. If this is a one-time clean-up you may also wish to query the database tables, like Docker* tables will allow you to eventually find what images you need to tag. Just don't delete from the database, since that can cause a headache and it won't delete files from disk Hope that helps :)

I don't agree with you. Sorry. Configuration is very simple and we are 100% sure that everything is ok with connection string. It was tested. So ok, we will buy a payment version and we will send a request to support. Thanks for help.

@jimbobmcgee thank you again for the very detailed analysis; we will get this fixed via OT-515, it's most an easy encoding to add

Hi @MY_9476 , Thanks for the heads up! We will fix this via OT-514 in the next maintenance release. As an FYI, this is the code that should have been run at the end of the database upgrade, to ensure that all procs and table-value params have appropriate permission: DECLARE @SQL NVARCHAR(MAX) SET @SQL = '' SELECT @SQL = @SQL + 'GRANT EXECUTE ON TYPE::' + QUOTENAME(name) + ' TO [OtterUser_Role] ' FROM sys.table_types SELECT @SQL = @SQL + 'GRANT EXECUTE ON ' + QUOTENAME(name) + ' TO [OtterUser_Role] ' FROM sys.procedures EXEC sp_executesql @SQL The script you ran works too :)

hi @hammel_7023 , Thanks for letting us know, you are correct... this is indeed a regression from PG-2859. What's happening is the upload stream is getting prematurely closed during the POM validation logic, which is what's causing this error to occur. I've just patched it now via PG-2868, and it'll get in the next maintenance release. Cheers, Alana

@jimbobmcgee excellent thanks!! Release has been published then :)

Hi @nachtmahr , It sounds like your Windows Integrated Authentication is broken. This is an operating-system level feature, and the only thing you can do in ProGet is turn it on, or turn it off. WIA is pretty buggy these days, and sometimes it just breaks. Here is more information: https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-integrated-authentication Hopefully just doing a reboot of the server will fix the problem. If not, then you'll have to troubleshoot it, which kind of sucks: https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-troubleshooting#integrated-authentication-not-working Note that you can disable WIA by using the Locked Out protocol: https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-troubleshooting#locked-out-restoring-default-admin-account Hope that helps, Alana

Thanks @steviecoaster! All that sounds great, especially since it won't require changing anything on our end :) Much appreciateD!!

Hi @dean-houston , Thanks for your response, at the end, we come to the same conclusion that something went wrong during the upgrade and some of the configuration blobs got deleted from the disk and also from the database table. Luckily, we have the backup, but we need to figure out which images are corrupted and need to be recovered. Gabor