Add GitHub Enterprise Server support

[aegilops]

The Action uses Octokit to download microsoft/component-detection but does not specify that it should be from github.com. This means use on GitHub Enterprise Server leads to trying to resolve that org/repo on the local server, which fails with a 404.

You can work around this by manually downloading the appropriate release binary in the Actions workflow before running this Action, e.g. with wget.

It then attempts to submit using the Dependency Submission Toolkit. I haven't worked out precisely why, but this fails with a Cannot read properties of null (reading 'toString') error in the toolkit.

[jhutchings1]

@advanced-security/advanced-security-dependency-graph Can you have a look?

[jonjanego]

@jhutchings1 afaict the dependency graph team has never contributed to this project but i've asked FR to take a look

[nihalraghuraj-assent]

Getting the same error: Cannot read properties of null (reading 'toString') on GHE version: 3.13.3
Any updates on this issue?

[jhutchings1]

I opened #67 to fix this. Need to get it reviewed and merged.

[nihalraghuraj-assent]

@jhutchings1 Thank you for your prompt response! Will test it once its merged.

[nihalraghuraj-assent]

@jhutchings1, any updates on the GHE support, Apologies for being persistent but this is quite urgent.

[jhutchings1]

Still waiting on the PR to be approved and merged. I'm the interim, you're welcome to use it by referencing tht action with @ghes-fix as the version. Let me know if that works for you.

[nihalraghuraj-assent]

I tested it with @ghes-fix:
Resulted in:

Error: HttpError: Must authenticate to access this API. - https://docs.github.com/enterprise-server@3.13/rest Error: Error: Failed to download latest release

Error: Cannot read properties of null (reading 'toString') Error: TypeError: Cannot read properties of null (reading 'toString')

Pls find my script below, I am still manually downloading the binary:

name: Dependency Submission

on:
  push:
    branches: [ master, develop ]
  pull_request:
    branches: [ develop ]
  workflow_dispatch:

jobs:
  Component-Detection-Dependency:
    runs-on: windows-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Execute restore
        run: dotnet restore ./Assent.Party.Api.sln      

      - name: Download component-detection.exe
        run: |
          $output = "${env:GITHUB_WORKSPACE}\component-detection.exe"
          if (Test-Path $output) {
            Write-Output "Component Detection file already exists at $output"
          } else {
            $url = "https://github.com/microsoft/component-detection/releases/download/v4.9.5/component-detection-win-x64.exe"
            Invoke-WebRequest -Uri $url -OutFile $output
            Write-Output "Component Detection file downloaded to $output"
          }
      - name: List files in the current directory and check if component-detection.exe exists
        run: |
          Get-ChildItem -Path "${env:GITHUB_WORKSPACE}" | Format-Table Name, Length, LastWriteTime
          $filePath = "${env:GITHUB_WORKSPACE}\component-detection.exe"
          if (Test-Path -Path $filePath) {
              Write-Output "Component Detection file exists"
          } else {
              Write-Output "Component Detection file does not exist"
              exit 1
          }

      - name: Component Detection dependency submission action
        uses: advanced-security/component-detection-dependency-submission-action@ghes-fix

Am I missing something here?

[jhutchings1]

@nihalraghuraj-assent Interesting. I didn't see that error on my test instance. I'll spin up a new instance and have a look. Your workaround is a good one, though, and definitely something folks should look at to unblock themselves in the interim.

[jhutchings1]

FYI, I am currently blocked on validating additional changes here while I figure out an issue with my GHES test instance. I should be able to loop back in the coming days.

[nihalraghuraj-assent]

Any updates on the issue @jhutchings1 ?

[jhutchings1]

I'm blocked on a gnarly testing environment issue. Suggest following the workaround above. That's long term supportable and mirrors what I'm trying to do in the action itself