-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build-Agent Issues after installing BCCH 6.0.17 #3527
Comments
Why are you installing PS Core on the build agents? Are you running Set-NAVServerConfiguration in the container or on the host? |
Well I'm installing PowerShell 7.4.2 (https://github.com/PowerShell/PowerShell/releases) - assumed that was the same as Powershell Core? The Set-NAVServerConfiguration is running inside the host with Invoke-ScriptInBcContainer. |
You mean it is running inside the container - right? Inside the container - PS7 is installed and configured - and for containers - PS7 is not needed on the host. Are you running any invoke-sqlcmd's on the host or are they running in the container as well? |
Yes, you are right - it's running inside the container. But you're saying that we don't need to install PS7 on the host/agent? PS: I'm right now waiting for an updated version of our agents, without PS7 installed - just to see if the problems goes away again by doing so, of if there is another issue. |
That is ALOps - I cannot say what requirements they have. But... - when using BcContainerHelper alone, PS5 and PS7 on the host are both fine. |
And... - since you are using BC 14 (I see in your log) - you really shouldn't need PS7 at all and you definitely shouldn't create a pwsh session in the container - that ONLY works with BC24. |
I tried to revert my agent build repo to how they were when the last time it ran successful. Which was last Friday. Running it without installing DotNet8 and PS7, same but same OS version etc. This failed with the same "The WSMan provider host process" error as mentioned above. As for BC 14, this is from my BC 14 test pipeline. We have other Pipelines running both v23 and v24 using the same build agents. |
I would need full logs (and if possible a script with a repro) if I am to look at anything. |
Also, I would always ask people to try using a Hosted agent from ADO or GitHub to see whether this is your agents or it ia indeed ContainerHelper or like. |
I decided to spend a bit more time on trying to fix the issues, instead of the same amount on collecting the logs and scripts we use. Because I could see that the error only occurred in connection to specific scenarios where I either change to/from multitenancy (using Export-NAVApplication and Remove-NAVApplication etc and creating a user via Invoke-SQLCmd) and places where I had previously been using version specific "12.0.0.0". In regards to the second error, then I just moved changing the call to Set-NAVServerConfiguration to change the Multitenant setting into its own call to Invoke-ScriptInBcContainer call. I remembered that I had experienced something similar in a different script 4-5 years ago, and moved other calls to Set-NAVServerConfiguration into they own Invoke. I'm not quite sure what in 6.0.17 broke this, but if anyone runs into the same issues and don't know how to solve it, then reply here or contact me for more information. |
Invoke-SqlCmd should be available for use in Invoke-ScriptInBcContainer automatically - you shouldn't have to load any special stuff???? |
Do you mean besides Microsoft.SqlServer.Smo? |
If I run this script:
It works just fine (except for failing with User, group, or role 'NT AUTHORITY\SYSTEM' already exists in the current database.) This works for BC24 (running PowerShell 7 with SqlServer PowerShell module version 22.2 installed in the generic image with overrides in psoverrides.ps1 because the latest Invoke-SqlCmd added a new parameter) |
The above script worked fine. So I tried with something that looked a bit more like our own code, but still only using "your" code. And here I were able to get the same errors.
The log for this task: 2024-05-03T11:30:51.9114880Z BcContainerHelper version 6.0.17 I'm in the process of running the same test for V23 and V24, and will post the result when I get home. |
The same tests with v23 and v24, did not give any errors. |
Tried the script and it looks like Export-NAVApplication in BC14 has a dependency on the smo thingy - not sure which versions has a dependency like this. |
As long as we have a way to fix it, then I'm fine with that. |
After I have installed Powershell Core (7.4.2) to our build agents I have started to see different errors when running our pipelines.
First our function to add new SQL users failed with:
Exception calling "Load" with "1" argument(s): "Could not load file or assembly 'Microsoft.SqlServer.SMO, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified."
This I could fix by changing the version specific load to:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO")
But after fixing it here, then it failed with the same error when we change the container to run Multi-Tenant, when running Export-NavApplication. I fixed that by adding the same load part you use in Restore-BcDatabaseFromArtifacts.
After fixing this, it failed when I was trying to mount the new tenant. Saying that server was not multitenant. Despite I had been running this statement first:
Set-NAVServerConfiguration -ServerInstance $ServerInstance -KeyName 'Multitenant' -KeyValue 'true' -ApplyTo ConfigFile -WarningAction SilentlyContinue
Changing this to:
Set-NAVServerConfiguration -ServerInstance $ServerInstance -KeyName 'Multitenant' -KeyValue 'true' -ApplyTo ConfigFile -Force -WarningAction Continue
This gave a new error: Processing data for a remote command failed with the following error message: The WSMan provider host process did not return a proper response. A provider in the host process may have behaved improperly.
I have no idea, how installing Powershell 7.4 can cause this effect, or if there has been any other updates to how the BC images are created, that could cause this. But I hope someone has experienced something similar, or have another input to what could be wrong.
Selected Logs from create new container:
BcContainerHelper is version 6.0.17
BcContainerHelper is running as administrator
HyperV is Disabled
Host is Microsoft Windows Server 2019 Datacenter - 10.0.17763.5696
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is allow
UseSslForWinRmSession is True
Docker Client Version is 26.1.1
Docker Server Version is 26.1.1
Style: onprem
Multitenant: No
Version: 14.44.49619.0
Platform: 14.0.49616.0
Generic Tag: 1.0.2.20
Container OS Version: 10.0.17763.5696 (ltsc2019)
Host OS Version: 10.0.17763.5696 (ltsc2019)
The text was updated successfully, but these errors were encountered: