Super-linter: GolangCI Lint fails with Private repo modules

[ahmedhosnycs]

Hi,

I've a Golang project that has a private dependency in go.mod file. I've tried to introduce Super Linter to my project, but unfortunately it always fails with the following error.

Issue

File:[<filename>.go]
ERROR! Found errors in [golangci-lint] linter!
ERROR:[level=error msg="Running error: context loading failed: failed to load program with go/packages: err: exit status 1: stderr: go: github.com/my/[email protected]: invalid version: git fetch -f https://github.com/my/privaterepo refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /github/home/go/pkg/mod/cache/vcs/44667f49551c110ac16611ad1211f82927c59fbf989271b121b7124840707cd8: exit status 128:
    fatal: could not read Username for 'https://github.com': terminal prompts disabled
"]

I've tried multiple solutions but none of them have worked.

Trial 1

    steps:
          ##########################
          # Checkout the code base #
          ##########################
          - name: Checkout Code
            uses: actions/checkout@v2

          ################################
          # Run Linter against code base #
          ################################
          - name: Super-Linter
            env:
              VALIDATE_ALL_CODEBASE: true
              DEFAULT_BRANCH: development
            uses: github/[email protected]
            with:
              repo-token: ${{ secrets.MY_TOKEN }}

Trial 2

steps:
          ##########################
          # Checkout the code base #
          ##########################
          - name: Checkout Code
            uses: actions/checkout@v2

          ################################
          # Run Linter against code base #
          ################################
          - name: Super-Linter
            env:
              VALIDATE_ALL_CODEBASE: true
              DEFAULT_BRANCH: development
              GONOPROXY: github.com/my/privaterepo
              GOPRIVATE: github.com/my/privaterepo
              GOPROXY: https://proxy.golang.org,direct"
              GITHUB_TOKEN: ${{ secrets.MY_TOKEN }}
            uses: github/[email protected]

Trial 3

    steps:
          ###################################
          # Granting private modules access #
          ###################################
          - name: Granting private modules access
            env:
              TOKEN: ${{ secrets.MY_TOKEN }}
              USERNAME: ${{ secrets.USER }}
              GONOPROXY: github.com/my
              GOPRIVATE: github.com/my
            run: git config --global url."https://${USERNAME}:${TOKEN}@github.com/".insteadOf "https://github.com"
          ##########################
          # Checkout the code base #
          ##########################
          - name: Checkout Code
            uses: actions/checkout@v2

          ################################
          # Run Linter against code base #
          ################################
          - name: Super-Linter
            env:
              VALIDATE_ALL_CODEBASE: true
              DEFAULT_BRANCH: development
            uses: github/[email protected]

Notes:

• I'm sure the token has the proper access.
• I've tried different mutation of those main three trials, all ends up with the same issue.

Let me know what am I doing wrong or how can I fix it?

Much appreciated in advance!

[zkoppert]

It looks like the issue could be access like you mentioned. You might try testing this in a public repository with the same workflow files to narrow down that it is indeed an access issue.

[zkoppert]

@ahmedhosnycs Is the repository that you are working on public? If so, can you provide a link. I'd like to try some troubleshooting.

[ahmedhosnycs]

@zkoppert Unfortunately the repository is not public but private and also importing modules from another private Go repos.

I do think it is indeed an access issue since linting YAML and MD files that are on the same repo are passing fine.

[itaischwartz]

had the same issue in my project.
In my case, the container that I used contained "InteadOf" directive in /etc/gitconfig that override my token "insteadOf" directive.
adding rm -f /etc/gitconfig and go get -t -v ./... before executing the linter solved the problem

[HatsuneMiku3939]

workaround

env:
  GOPRIVATE: ADD_USER_PRIVATE_MODULE_HERE

###############
# Set the Job #
###############
jobs:
  lint:
    # Name the Job
    name: Lint Code Base
    # Set the agent to run on
    runs-on: ubuntu-latest
    container: github/super-linter:v3

    ##################
    # Load all steps #
    ##################
    steps:
      ##########################
      # Checkout the code base #
      ##########################
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Configure git for private modules
        env:
          ACCOUNT: ${{ secrets.GITHUB_ACCOUNT_USER }}
          TOKEN: ${{ secrets.GITHUB_ACCOUNT_TOKEN }}
        run: git config --global url."https://${ACCOUNT}:${TOKEN}@github.com".insteadOf "https://github.com"

      ################################
      # Run Linter against code base #
      ################################
      - name: Lint Code Base
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: master
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: /action/lib/linter.sh

[jdhom]

@HatsuneMiku3939 looks similar to the docker workaround I use. If you add the private org to the replace you can prevent sending your token on all github requests.

git config --global url."https://${GITHUB_TOKEN}:[email protected]/private-org".insteadOf "https://github.com/private-org"

[zkoppert]

Anybody got some time to add this workaround to the super linter documentation? maybe @jdhom or @HatsuneMiku3939 ?

[HatsuneMiku3939]

@zkoppert
OK. I will do it.

[ahmedhosnycs]

@HatsuneMiku3939 This workaround has worked for me. Many Thanks 🙏

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[estensen]

Could this issue be reopened until this is added to the docs?