What is the status of using the CLI Scanner on MacOS Arm64 (M1/M2/M3) since this is the only hardware available to purchase new these days. Currently we are unable to scan our mobile applications as the build’s happen on macos hardware with the M2 chips…
Hey there.
You should have no problems running the SonarScanner CLI on ARM Macs (every SonarSourcer who gets a Mac these days is getting an ARM Mac).
… which definitely makes it confusing that the docs say:
The SonarScanner CLI is the scanner to use when there is no specific scanner for your build system. The SonarScanner CLI does not support ARM architecture.
I’ll flag that for attention.
What trouble do you run into when you use the CLI on an ARM mac?
Thats what you would thing right… but I get the following error:
Initialize SonarQube for CLI
- Starting: Initialize SonarQube for CLI
==============================================================================
Task : Prepare Analysis Configuration
Description : Prepare SonarQube analysis configuration
Version : 5.19.0
Author : sonarsource
Help : Version: 5.19.0. More Information
==============================================================================
##[error]An error occurred trying to start process ‘/Applications/AZAgent/A1/externals/node10/bin/node’ with working directory ‘/Applications/AZAgent/A1/_work/1/s’. Bad CPU type in executable
Finishing: Initialize SonarQube for CLI
Hey there.
Can you share your Azure Pipelines YML?
Certainly… Right now the sonarqube steps are disabled since they dont work at this point…
parameters:
- name: release
displayName: 'Build a release build?'
type: boolean
default: false
steps:
- checkout: self
lfs: true
- script: |
bundle install
displayName: Install Prerequisites
- task: InstallAppleCertificate@2
inputs:
certSecureFile: '$(DIST_CERT_NAME)'
certPwd: '$(DIST_CERT_PASS)'
- task: SonarQubePrepare@5
displayName: Initialize SonarQube for CLI
condition: false
inputs:
SonarQube: SonarQube
configMode: 'manual'
scannerMode: 'CLI'
cliProjectKey: 'mobile.<appname>-ios' //Edited for privacy
cliProjectName: '<appname>-ios' //Edited for privacy
cliProjectVersion: $(Build.BuildNumber)
cliSources: <appname>
extraProperties: |
# Additional properties that will be passed to the scanner,
# Put one key=value per line, example:
#sonar.scm.provider=git
- ${{ if eq(parameters.release, true) }}:
- script: bundle exec fastlane lane_release_build
- ${{ else }}:
- script: bundle exec fastlane lane_adhoc_build variant:Debug_External
- task: SonarQubeAnalyze@5
condition: false
- task: SonarQubePublish@5
condition: false
inputs:
pollingTimeoutSec: 300
- task: CopyFiles@2
inputs:
contents: '**/*.ipa'
targetFolder: '$(build.artifactStagingDirectory)'
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: drop-iOS'
inputs:
ArtifactName: 'drop-iOS'
The build is a two part… above is the azure-build-template.yml…
here’s the azure-pipelines.yml
# Pipeline to build and distribute LandstarOne
trigger:
tags:
include:
- 'v*'
branches:
include:
- develop
pool:
name: OnPrem - MacOS
variables:
CI_PIPELINE_ID: $(Build.BuildId)
CI_COMMIT_SHORT_SHA: $(Build.SourceVersion)
CI_COMMIT_REF_NAME: $(Build.SourceBranchName)
stages:
# ==============================
# Build Stage
# ==============================
- stage: build
displayName: Build
jobs:
- ${{ if contains(variables['Build.SourceBranch'], 'refs/tags/v') }}:
- job: release_build
displayName: 'Release Build'
steps:
- template: azure-build-template.yml
parameters:
release: true
- ${{ else }}:
- job: internal_build
displayName: 'Internal Build'
steps:
- template: azure-build-template.yml
parameters:
release: false
# ==============================
# Deploy Stage
# ==============================
- stage: deploy
displayName: Deploy
dependsOn: build
jobs:
- ${{ if contains(variables['Build.SourceBranch'], 'refs/tags/v') }}:
- job: release_upload
displayName: 'Release Upload'
steps:
- template: azure-upload-template.yml
parameters:
release: true
- ${{ else }}:
- job: internal_upload
displayName: 'Internal Upload'
steps:
- template: azure-upload-template.yml
parameters:
release: false
Okay. I think I have an idea about what is going on. The issue is actually with running the Azure DevOps task, not the scanner itself.
To give you some history: for a long time, Azure DevOps build tasks could either run on Node 6 or Node 10. Those were the options. The last time we updated the execution handler used, we went up to Node 10 (and now Node 6 isn’t supported anymore)
Here’s that bit of code.
Nowadays Node 16 and Node 20 are supported (which have distributions for MacOS ARM64), but it’s not super trivial to update the execution handler (at least, it wasn’t last time) as that can change what versions of Azure DevOps are supported.
All of that said, I’m going to hand this over to the right team to investigate what can be done, and maybe they’ll have an idea of some workaround (I thought maybe you can launch your agent using Rosetta, but that just sounds horrible). I think we’re about to bump the major version of our task anyways, so it might be a good time.
I’m surprised we don’t hear more about this, but I guess Azure DevOps only supports self-hosted macos arm agents.
Ah okay, actually, using Rosetta 2 is the suggested workaround.
…and we should still migrate to at least Node16 someday. so i’ll still ping around.
Hello @gizmohd , we have a task [VSTS-356] - Jira that will bring a new major version of the SonarQube tasks. Among other things, these tasks will run on more recent NodeJS version (18+), which should solve your issue.
Our effort to release this new major version is not yet planned, but you can follow progress and have all the information on the upcoming update in the ticket I linked above.