Compressed symlink is not supported in master

SonarQube Cloud
1

Hi Team! We are getting the below issue as well… unzip: compressed symlink is not supported in master …Is there a way to fix this? Currently we have moved into v3.1.0…

1 Like
2

Hi @nantha4ever,

Thanks for reporting your issue: it helps us stabilizing v4 of the GitHub action.

This seems a different issue, as it happens on unzip, rather than mv.

Would you please open a new thread in the community? We can continue the discussion there.

Thanks,
Antonio

3

I had the same issue when using on alpine, moving to ubuntu fixed the issue.

1 Like
4

2 posts were merged into an existing topic: Sonarsource/sonarqube-scan-action@master failed to install sonar-scanner-cli

5

Hi Support Team!

We are getting the below issuw… unzip: compressed symlink is not supported in master …Is there a way to fix this? Currently we have moved into v3.1.0…

7

Hi @nantha4ever,

Are you using alpine in your workflow? If so, would you try applying @ppamorim’s solution and see whether it fixes your issue?

Thanks,
Antonio

1 Like
8

It is also failing in all my projects, and I’m using ubuntu.
This worked correctly 3 weeks ago:

9

Hi @Sergio_Castineyras,

Thanks for reporting your issue to our community.
When I check your workflow here, I see the following job declaration:

name: CKAN ${{ matrix.ckan-version }}
    runs-on: ubuntu-latest
    container:
      image: openknowledge/ckan-dev:${{ matrix.ckan-version }}
    ...

The openknowledge/ckan-dev Docker image seems to be defined here.

The base image of that Docker image is Alpine:

FROM alpine:3.15

...

So, I think that the runs-on: ubuntu-latest declaration in your job definition is “overwritten” by the container declaration.

Could you try to:

  • either remove the container declaration
  • or get a ubuntu-based container, to run the analysis on?

If neither of the two options is available for you, as you need to run the previous steps in an environment based on openknowledge/ckan-dev, you may have two separate jobs:

  • one running in openknowledge/ckan-dev and doing the necessary Python commands
  • the other one running the analysis

You would then need to transfer artifacts from one to the other.

Let me know if you get it to work,
Best regards,
Antonio

10

I’d say it’s easier to fix the root cause, so I don’t need to change anything, again, this has been working for the last year with no issues until 3 weeks ago

11

Hi @Sergio_Castineyras,

The root cause is the removal of Docker from the GitHub action, that happened in v4.0.0. We made that change to fix a variety of issues, reported to us by multiple of our customers, all coming from the use of Docker.
You can read more about this change in this community post.

Removing Docker fixed many of the issues our users had, but unfortunately seems to have came with the cost of not being able to support alpine from the day 1. We may look into this in the future, but there are currently no plans to specifically overcome alpine limitations on unzip.

So I would first try to see if we can easily fix your pipeline by removing the container, to make sure that your issue actually comes from alpine.

Best regards,
Antonio

1 Like
16

Hi Antonio,
I’m using ubuntu-latest in my GH Action, no container defined that would overwrite it and I am experiencing the same issue. Maybe you have some tips?

GH Action is using the upstream one from sonar as you can see here:

name: SonarQube

on:
  push:
    branches:
    - 'main'

jobs:
  tag:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: SonarQube Scan
        uses: sonarsource/sonarqube-scan-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
17

Hi @SebastianC,

Would you double-check what is the precise OS that is running the GitHub Action? You can check that in the Set up job logs:

image
image1465×418 33 KB

It would be useful if you could share the full logs of all the steps of your job.

Thanks,
Antonio

18

Hi Antonio,
sure. I am attaching the raw logs, I’ve only removed the digest and repository name references since this is after all a public forum.

From the attached log: here are the image details:

2025-01-08T10:49:50.0737364Z Image: ubuntu-24.04
2025-01-08T10:49:50.0738030Z Version: 20241215.1.0
2025-01-08T10:49:50.0739239Z Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20241215.1/images/ubuntu/Ubuntu2404-Readme.md
2025-01-08T10:49:50.0740849Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20241215.1

job.log (20.0 KB)

Let me know if I can do something else to help debug this issue.

19

Hi @SebastianC,

Thanks a lot for the logs!

Would you confirm that the workflow above is the complete workflow you are running?

From your logs, I have the impression that the GitHub action is running in a container, and not directly in the Ubuntu 24.04.1 of the GitHub runner.

For example the temporary directory to download and unzip the scanner is created under /__w/_temp:

2025-01-08T10:50:14.4795703Z + mkdir -p /__w/_temp/sonarscanner
2025-01-08T10:50:14.4813968Z + cd /__w/_temp/sonarscanner

Whereas the default RUNNER_TEMP location should be /home/runner/work/_temp, so the logs should look something like the following:

2025-01-08T11:31:11.6998119Z + mkdir -p /home/runner/work/_temp/sonarscanner
2025-01-08T11:31:11.7012223Z + cd /home/runner/work/_temp/sonarscanner

It would also be great if you could run the cat /proc/version, cat /etc/os-release, and uname -a commands in a step between the Checkout and the SonarQube Scan, just to make sure you are running in the right environment.

Thanks,
Antonio