Github action should fail on authentication error

When building and running a github action, the secret is missing from my sonarcloud.io. The build fails but the error is displayed as a warning and 5 lines later, the build outputs 0 warnings. I think this should be an error and the build should fail.

Logs example:

08:10:55.315 Updating build integration targets…

08:10:55.711 WARNING: Authentication with the server has failed.

08:10:55.711 WARNING: In version 7 of the scanner, the default value for the sonar.host.url changed from “http://localhost:9000” to “https://sonarcloud.io”.

If the intention was to connect to the local SonarQube instance, please add the parameter: /d:sonar.host.url=“http://localhost:9000

08:10:55.712 Pre-processing failed. Exit code: 1

Determining projects to restore…

Restored D:\a\EndToEndSecurity\EndToEndSecurity\server\BffMicrosoftEntraID.Server.csproj (in 17.74 sec).

BffMicrosoftEntraID.Server → D:\a\EndToEndSecurity\EndToEndSecurity\server\bin\Release\net9.0\BffMicrosoftEntraID.Server.dll

Build succeeded.

0 Warning(s)

0 Error(s)

I faced the same behavior.
I would also prefer the auth warning to be an error instead so that the actions workflow fails at this point.

Furthermore, I could resolve the issue by recreating the sonarqube cloud token and update the value in GitHub actions secrets. However, I was wondering why my former token was not there anymore in SonarQube Cloud. Any idea? Was this erased while the migration of the plans by Sonar?

Hey @damienbod

Can you share your full GitHub actions workflow?

@rufer7 Sounds like it might be related to this:

1 Like

Thank you @Colin for the hint. Seems to match, yes. My token was inactive for more than 60 days. This automatic deactivation is unexpected and imho unintentional (i.e. if you set it up for a project that is in maintenance mode and gets updates every half a year for example).

Find my example (incl. GitHub actions workflow) here. For an example of the warning log entry, see this run

I think that adding $ErrorActionPreference = "Stop" would provide the behavior you’re looking for. Can you try it out?

- name: Build and analyze
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        shell: powershell
        run: |
          $ErrorActionPreference = "Stop"
          .\.sonar\scanner\dotnet-sonarscanner begin /k:"rufer7_github-sonarcloud-integration" /o:"rufer7" /d:sonar.token="${{ secrets.SONAR_TOKEN }}" /d:sonar.host.url="https://sonarcloud.io" /d:sonar.projectBaseDir="D:\a\github-sonarcloud-integration\github-sonarcloud-integration" /d:sonar.cs.vscoveragexml.reportsPaths=coverage.xml
          dotnet build .\src\ArbitrarySolution.sln --configuration Release
          dotnet-coverage collect 'dotnet test .\src\ArbitraryProject.Tests\ArbitraryProject.Tests.csproj' -f xml  -o 'coverage.xml'
          .\.sonar\scanner\dotnet-sonarscanner end /d:sonar.token="${{ secrets.SONAR_TOKEN }}"

It might make sense that this goes in the official tutorial… surprised it hasn’t come up before now

1 Like

Unfortunately same behavior as before.

See Try suggestion from Sonar Community · rufer7/github-sonarcloud-integration@0825860 · GitHub

My expected behavior requires WARNING: Authentication with the server has failed. to be an error (throw exception!?) instead of just logging a warning.

weird. I’m calling in reinforcements!

1 Like

Hello @rufer7

in the log, you can see that the begin command exited with exit code 1.

11:38:13.569  Pre-processing failed. Exit code: 1

$ErrorActionPreference as suggested by @Colin is the right idea, but it sets the stop behavior for powershell CmdLets but is ignored for native commands by default. dotnet-sonarscanner is a native command and you can make $ErrorActionPreference work for it by setting $PSNativeCommandUseErrorActionPreference to $true. For more details see also: Stop a script when an error occurs in PowerShell - Meziantou's blog

You can experiment with this ps1 script locally to see the differences:

$ErrorActionPreference = "Stop"
$PSNativeCommandUseErrorActionPreference = $true
robocopy Nonexistent
Write-Host "I'm still running."

Prints:

...
ERROR : No Destination Directory Specified.
...
NativeCommandExitException: C:\test.ps1:3
Line |
   3 |  robocopy Nonexistent
     |  ~~~~~~~~~~~~~~~~~~~~
     | Program "Robocopy.exe" ended with non-zero exit code: 16.
1 Like

@Martin_Strecker thank you for your investigations and for the reply! Much appreciated.
I just tested the recommendations and it seems like it didn’t work as expected (see here). Build command still gets executed.

@Martin_Strecker seems to me like the main method of the dotnet-sonarscanner should return void or may Task instead of Task<int> to make it work as expected - otherwise the Environment.ExitCode property gets ignore as far as I understand from the docs.

See Environment.ExitCode Property - Remarks

Hello @rufer7

It looks like your workflows run on windows-latest with Powershell Desktop.

$PSNativeCommandUseErrorActionPreference is supported on Powershell Core 7.4. and above only. Please change the shell to pwsh. See also here for more details:

See also this discussion on GitHub actions which is exactly about your problem:

Regarding the exit code you are right, in the sense that Environment.ExitCode is ignored, but we also return the right exit code from main, so that it is still propagated:

> dotnet-sonarscanner begin
...
Expecting at least the following command line argument:
...
Pre-processing failed. Exit code: 1

> $LASTEXITCODE
1

@Martin_Strecker thanks for analyzing and investigation! Much appreciated.

I just changed the shell to pwsh, added $ErrorActionPreference = "Stop" and $PSNativeCommandUseErrorActionPreference = $true and now it seems to work as expected.

To be honest, it’s not really intuitive that ErrorActionPreference and PSNativeCommandUseErrorActionPreference have to be set.

Thanks a lot for your support.

1 Like

@rufer7 I’m glad to hear it worked and thank you for your patience.

To be honest, it’s not really intuitive that ErrorActionPreference and PSNativeCommandUseErrorActionPreference have to be set.

We agree, but there is nothing we can do to improve the situation, except updating our documentation by adopting your setup (Powershell Core and “fail-fast”). I created a ticket for our documentation team to do this.
Maybe Github Actions change the default for scripts in the future, but this would be a breaking change and will likely not happen.

1 Like