Enable localhost:port as possible URL for migration source

[s-rick]

It would be nice,to be able to use locally running or forwarded URL as the migration source.
This would enable migration from ci/cd solution not having a dedicated URL.
gh actions-importer audit jenkins --output-dir audit --jenkins-instance-url localhost:8666
This could be achieved by enabling the --network=host option in then running the container.
I think this is already used in the unittest.

Example of the problem:

$ gh actions-importer audit jenkins --output-dir audit                                    
[2023-04-04` 12:16:09] Logs: 'audit/log/valet-20230404-121609.log'
[2023-04-04 12:16:09] Auditing 'http://localhost:8666'
[2023-04-04 12:16:09] Failed to connect to 'http://localhost:8666/api/json?tree=jobs%5Bname%2Curl%2CfullName%5D'. Please ensure the server is reachable and your environment variables and options are set correctly. Error: Failed to open TCP connection to localhost:8666 (Connection refused - connect(2) for "localhost" port 8666)
Extracting all pipelines: |=---=---=---=---=---=---=---=---=---=---=---=---=---|

[ethanis]

@s-rick this is possible by setting the DOCKER_ARGS variable before you run Actions Importer commands. For example:

DOCKER_ARGS="--network=host" gh actions-importer audit jenkins --output-dir audit

[usmonster]

I just updated to 1.3.2 (released 2 days ago) and am still having the same error 😩

Is there something I'm missing? FYI, I've done a kubectl port-forward first (to get around our configured SSO), but I can still curl the forwarded endpoint fine. Please let me know if I should open a separate thread.

Thanks again!

[ethanis]

@usmonster can you share the exact command and console output when you run into the error? Also, can you share what the value of the $DOCKER_ARGS environment variable is?

[usmonster]

Sure, it's pretty much identical to the original post:

$ gh actions-importer update
Updating ghcr.io/actions-importer/cli:latest...
ghcr.io/actions-importer/cli:latest up-to-date
$ gh actions-importer version
gh version 2.29.0 (2023-05-10)
gh actions-importer     github/gh-actions-importer      v1.3.2
actions-importer/cli:latest     v1.3.19087
$ gh actions-importer audit jenkins --no-http-cache --github-access-token "$(gh auth token)" -f MyJob -o .
[2023-05-24 15:49:36] Logs: './log/valet-20230524-154936.log'
[2023-05-24 15:49:36] Auditing 'http://localhost:8080'
[2023-05-24 15:49:39] Failed to connect to 'http://localhost:8080/job/MyJob/api/json?tree=jobs%5Bname%2Curl%2CfullName%5D'. Please ensure the server is reachable and your environment variables and options are set correctly. Error: Failed to open TCP connection to localhost:8080 (Connection refused - connect(2) for "localhost" port 8080)
Extracting all pipelines: |=---=---=---=---=---=---=---=---=---=---=---=---=---|
$ curl http://localhost:8080/job/MyJob/api/json?tree=jobs%5Bname%2Curl%2CfullName%5D
{"_class":"jenkins.branch.OrganizationFolder","jobs":[ ... ]}

Some more context:

• DOCKER_ARGS is empty in my session (I don't set it)
• Running Rancher Desktop with the dockerd (moby) container engine
• On MacOS Monterey
• Running a kubectl port-forward jenkins 8080 in a separate terminal window (context pointing to non-local staging env)

Please let me know if you need anything else (log contents? telemetry transaction id?), and thanks again for the support!

[ethanis]

Hmm I wonder if your docker install isn't picking up the right networking rules from your host machine. Can you try running this command to verify that docker itself is able to connect to the server running on localhost?

 $ docker run --rm curlimages/curl http://localhost:8080

[usmonster]

Indeed, this seems to be the issue:

$ docker run --rm curlimages/curl -sSI http://localhost:8080
curl: (7) Failed to connect to localhost port 8080 after 0 ms: Couldn't connect to server

...thanks for the hint! This works better (because Mac):

$ docker run --rm curlimages/curl -sSI http://host.docker.internal:8080
HTTP/1.1 200 OK
...

I'd say this is solved for me (though not sure if it makes sense to add any warning to the extension or its documentation since it's really a known Docker for Desktop Mac/Windows limitation). Thanks yet again!