Posts made by williamb_5729

When sending a request to FindPackagesById(), the response contains a Cache-Control header with a value of private.

The MSBuild scripts associated with dotnet tool are not ignoring the Cache-Control header and in some cases is caching the response to FindPackagesById(). This can cause a dotnet tool update command to not recongize newer versions of a tool.

The Cache-Control header for any API request should probably return: no-cache, no-store, must-revalidate to ensure that the HTTP client does not cache the response.

Product: ProGet
Version: 5.1.15

I've reread the documentation for Execution Modes. I believe I have a better understanding of executionPolicy's purpose now.

The Create-File operation will create the directory. Using $WorkingDirectory as the location of the file ensures that that path is created and will be removed after execution completes.

Still, Get-Asset should ensure the destination directory exists.

The Get-Asset operation does not ensure the $WorkingDirectory exists. This leads to an exception if the directory has not been created by a previous operation.

The Ensure-Directory operation will create the $WorkingDirectory, but it then becomes a configuration item that is reported on the Server's configuration page.

I cannot locate a function that simply creates a directory if it does not exist. The Get-Asset operation should ensure that the working directory exists when copying the asset, similar to some other operations.

Is there a workaround other than Ensure-Directory?

Product: Otter
Version: 2.0.12

The executionPolicy within a block seems to be ignored.

I have a module defined as:

module X 
{
  {
    with executionPolicy = always 
    {
      Restart-Server();  
    }
    
    PSEnsure 
    {
       .. removed to brevity ...
    }
    
    Execute-PowerShell dir
    (
    );
    
    {
       Execute-PowerShell dir ();
    }
    
    with executionPolicy=onChange
    {
      Restart-Server()
    }
  }
}

In testing, the first Restart-Server never executes. I am working under the assumption it should always execute.

The first Execute-PowerShell dir -- executes only if the PSEnsure finds a change. This is expected.

The second Execute-PowerShell dir -- never executes, even when PSEnsure finds a change. Shouldn't a nested scope also be included in the change execution?

The second Restart-Server never executes.

Based on these results, it seems that executionPolicy has no discernible effect. How does executionPolicy actually work?

Product: Otter
Version: 2.0.12

John, I created a second Database raft and set the server's raft to "Default" before reporting the issue. It did not resolve the error.

The Jobs table in the database will not allow a "RaftId" that is not null for a job with a JobType of "C" . The Jobs table has a CK_Jobs_Raft_Id that enforces the null Raft_Id constraint.

I've temporarily worked around the issue by modifying the Jobs_Extended view to adjust Raft_Id to 1 when it would otherwise be NULL.

When preparing to execute a remediation configuration job:

Inedo.Otter.Service.Executions.ActiveJobExecution.BuildConfigurationExecuter always throws a NullReferenceException.

The code (found in the above mentioned method):

      using (RaftRepository raft = RaftRepository.OpenRaft(job.Raft_Name))
        variables = await raft.GetVariablesAsync().ConfigureAwait(false);

always fails. job.Raft_Name is always null, which causes RaftRepository.OpenRaft to return null. In turn, raft.GetVariablesAsync() results in a NullReferenceException.

As this stands, it is impossible to execute a configuration remediation job.

Product: Otter
Version: 2.0.11

I have just begun evaluating Otter. I currently have a Windows 2012 R2 instance running the Otter Agent.

The server is a member of the IIS role, which itself is a member of the Configurable role.

The Configurable role has a plan that is defined as:

##AH:UseTextMode
call Ensure-PowerShell-5();

The Ensure-PowerShell-5 module is stored in a Git based Raft, named Default. The module itself is defined as:

##AH:UseTextMode
##AH:Description Ensure PowerShell version 5 or later is installed.
module Ensure-PowerShell-5
{
    # Ensure PowerShell version 5 or later is installed
    {
        PSEnsure
        (
            Key: PowerShell-v5,
            Value: True,
            Collect: $PSVersionTable.PSVersion.Major -ge 5,
            Configure: '@(Get-Service | Where-Object {$_.Name -eq "INEDOBMAGT"}).Count',
            Debug: true,
            Verbose: true
        );

        # Only executes if PSEnsure Configure executed
        Restart-Server();
    }
}

The Ensure-PowerShell-5 module is currently incomplete, but it does properly detect configuration drift. When attempting to remediate the drift by choosing the Remediate with Job button on the Servers page, the execution fails.

The Service log contains the error:

Category: ExecutionDispatcherRunner
Message: Could not initiate execution #334
Details: 
System.NullReferenceException: Object reference not set to an instance of an object.
at Inedo.Otter.Service.Executions.ActiveJobExecution.<BuildConfigurationExecuter>d__4.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.Otter.Service.Executions.ActiveJobExecution.<CreateJobExecutionAsync>d__3.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.Otter.Service.Executions.ActiveExecution.<CreateAsync>d__3.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.Otter.Service.Executions.ExecutionDispatcherRunner.<RunAsync>d__7.MoveNext()

Orchestration Plans will run successfully.

Any assistance in determining the cause of this failure would be greatly appreciated. As it stands, I can detect drift, but am unable to remedy the situation.

Product: Otter
Version: 2.0.11