I can confirm this behavior too the PowerShell Gallery connector only shows it having 397 packages, but there are currently 3,940 unique packages available via powershellgallery.org. I am unable to install modules such as Carbon.
markrobertjohnson
@markrobertjohnson
Best posts made by markrobertjohnson
Latest posts made by markrobertjohnson
-
RE: PowerShell connector failing to pull from PowerShell Gallery
-
RE: Raft variables are not working
After some digging I determined that Mpa (%) types are not currently supported. I was able to get past this by embedding JSON in a scalar string, and then use %FromJson() to convert to a Map type in OtterScript.
-
Raft variables are not working
I have decided that using the Raft Variables appears to be my best option for storing configuration data that is tied to the current raft. I was going to use JSON in File assets, but the Get-Asset operation requires that the raft is explicit, which will not work for the "Promotion" use case (only if there were some way to get the "Current" raft in a variable or something).
I figured out how to add the "variable" file to the raft, and was able to debug the code that is reading the variable data (ReadVariables() in GitRaftRepositoryBase.cs of Git extension)
This is what I have in that file currently:
set %ChocolateyPackagesBuild = %( git.install: 2.18.0, nodejs.install: 10.11.0 ); set %ChocolateyPackagesCommon = %( googlechrome: 69.0.3497.9200, notepadplusplus.install: 7.5.7, git.install: 2.18.0, Sysinternals: 2018.7.19 );
But when the variable is used I get the error:
Unhandled exception: System.ArgumentException: Invalid variable value type. at Inedo.Otter.Service.PlanExecuter.ExecutionVariable..ctor(RuntimeVariableName name, RuntimeValue value) at Inedo.Otter.Service.PlanExecuter.OtterPlanExecuter.TryGetGlobalVariable(RuntimeVariableName variableName, IExecuterContext context) at Inedo.ExecutionEngine.Executer.ExecuterThread.ResolveVariable(RuntimeVariableName name, IExecuterContext context) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuterContext.GetVariableValue(RuntimeVariableName variableName) at Inedo.ExecutionEngine.Variables.VariableTextValue.<EvaluateAsync>d__7.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Inedo.ExecutionEngine.Variables.ProcessedString.<EvaluateAsync>d__13.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Inedo.ExecutionEngine.Executer.ExecuterThread.<ExecuteAsync>d__47.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Inedo.ExecutionEngine.Executer.ExecuterThread.<ExecuteNextAsync>d__35.MoveNext()
Is there something else I need to do in the variables file to make this work?
Product: Otter
Version: 2.0.10 -
RE: Otter: Output variables from PSCall
Hi Alana,
The "with execute=always { }" is great to know about, that would allow me to run the PSCall operation during both the collection and execution phases. PSCall still lacks the ability to return OtterScript Lists (which PSEval does do), so for now, I would have to return a delimited string and split apart with $Split.With regard to executing script assets via PSEval, I think any of the 3 options you provided would be fine, but I would also need the ability to pass parameters into the script asset (probably an OtterScript Map of the parameters same as PSCall).
Another option might be to modify the PSCall operation to support an "execute: always" optional parameter. Also, add a default output parameter/variable that captures all PowerShell object stream content (rather than requiring setting a specific output variable) that could return both Scalar and Vector OtterScript variables.
Thanks!
-
RE: Best practices for dealing with executions that to not stop
The agent version is 35.0.0.2
The next thing is the plan itself. What operation is it stuck on? Does cancelling the execution have any effect?
This may sound dumb, but I am not sure how to cancel an execution from the UI. I am able to call the "/api/json/Executions_DeleteExecution?API_Key=$apiKey&Execution_Id=$id" native API method, but I don't think that is what you are talking about.
Looking at the executing plan's log output, the last entry is an "Ensure Asset" of a file during the collection phase. It is sitting at "Comparing configuration..." but has not output the expected "INFO: Configuration matches template.". It is iterating though an array of asset names and is stuck on the 5th item of 6 total items.
Here is the plan:
##AH:UseTextMode # Loop foreach $assetName in @TeamCityPluginAssetNames { # General with retry = 3 { Ensure-Asset ( Name: $assetName, Type: File, Directory: c:\TeamCity\.BuildServer\plugins ); } }
Ideally, I would like to create a way to automatically remediate the long running execution scenario, perhaps a nightly Otter job that checks all server executions, and when one is found it restarts the INEDOAGENTSVC on the respective server agent.
-
Best practices for dealing with executions that to not stop
Currently I have two Otter agents that have executions that have been running for days. I am not sure what is wrong with them, but I want to properly terminate the executions and make sure the agents are in a good state. What is the best practice for dealing with this? I am planning the following approach (pseudo code):
foreach host with long running execution { delete the execution using native Otter API #Is this service restart needed? restart the INEDOAGENTSVC running on the host }
-
Otter is displaying a credential password in the execution log
I am using the $GetCredentialProperty(cred,Password) to pass a password into a powershell script in a PSEnsure statement. The execution log renders all of the input parameters, including the password (as DEBUG log items). Is there a way to redact the the password? perhaps just turning off DEBUG log messages would be sufficient, but I do not know how to turn those DEBUG log messages off.
#PSEnsure Statement
PSEnsure
(
Key: ConfigureNpm,
Value: 0,
CollectScript: Test-DefaultNpmRegistry,
ConfigureScript: Set-NpmConfiguration,
UseExitCode: true,
CollectScriptParams: %(
RegistryUrl: "$DefaultNpmPullRegistryUrl"
),
ConfigureScriptParams: %(
RegistryUrl: $DefaultNpmPullRegistryUrl,
RegistryUsername: $GetCredentialProperty(devbuilder,Username),
RegistryPassword: $GetCredentialProperty(devbuilder,Password),
UserProfileName: $GetCredentialProperty(devbuilder,Username)
)
);
#Log Output
DEBUG: Found script Set-NpmConfiguration.ps1 in Default raft.
DEBUG: Assigning parameter RegistryUrl=http://proget.internal.com/npm/npm
DEBUG: Assigning parameter RegistryUsername=builderusername
DEBUG: Assigning parameter RegistryPassword=<PASSWORD_IS_RENDERED_HERE>
DEBUG: Assigning parameter UserProfileName=builderusername