mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #1632] Unable to clone setup-java #813
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#813
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Andromelus on GitHub (Feb 17, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/1632
Bug report info
Command used with act
Describe issue
Watning to debug a workflow, I tried this tool.
Using the windows release (act_Windows_x86_64.zip, v0.2.42), I just launched act.
It seems to not be able to clone some actions repo.
However, I can clone manually:
Note that I am being a corporate proxy, if that matters.
Link to GitHub repository
https://github.com/Andromelus/hdfs
Workflow content
Relevant log output
Additional information
No response
@catthehacker commented on GitHub (Feb 23, 2023):
Your DNS is not working in Docker engine
@alex1701c commented on GitHub (Aug 9, 2023):
I have a similar issue, it seems like my http/https proxy setting is ignored.
What is also interesting is that I get the error on setup-node before my first step (
printenv) is being run.Edit: If I unset http_proxy and https_proxy as my ENV variable, I get the same error when trying to download act from github. But with those values set to my company proxy, it works fine to download the executable using wget.
@ChristopherHX commented on GitHub (Aug 9, 2023):
Seems like go-git ignores proxy env variables by default.
The cmd package would need to install a http client configured to support proxies: e.g. the default go http client
github.com/go-git/go-git@cd6170c6f8/_examples/custom_http/main.go (L39C51-L39C51)Source https://stackoverflow.com/a/62381987
EDIT Could also be a misconfigured proxy, which don't support golang.
github.com/go-git/go-git@cd6170c6f8/plumbing/transport/http/common.go (L131)indicates go-git should support HTTP_PROXY, HTTPS_PROXY and
NO_PROXYas documented by golang@alex1701c commented on GitHub (Aug 10, 2023):
Hmm, the values are the exact same as the ENV variables I use in a shell and there wget works only with the variables set.
But the exact same command works fine in a shell with the same proxy setup. Though this made me wonder if the clone would work fine if done as a step in the job.
It turns out it would fail due to missing certificates. If I were to manually hop into a container running the given image, apt install the certificates, it would work fine. With GIT_SSL_NO_VERIFY set to true as an ENV variable, cloning works as a setp. But when commenting setup-node back in again, the entire job fails with the above error.
@ChristopherHX commented on GitHub (Aug 10, 2023):
I'm not using proxies myself / No access to real world proxies.
Yeah I have the same problem with interacting with my self signed Certificate from containers.
The actions are cloned by go-git, that's not the git cli you use from cli. (Even if logs of act are implying the opposite). Also it runs outside of the container, so .env and --env are ignored.
Does this go-git example fail on your end?
github.com/go-git/go-git@cd6170c6f8/_examples/clone/main.goJust to make shure if the issue is in act or in go-git.
Can my downstream project, which should work with proxies https://github.com/christopherhx/github-act-runner connect to github.com via your proxy?
It's also a golang app, but using http directly. You can use a dummy token for configure to see if it reaches GitHub or not.
@alex1701c commented on GitHub (Aug 10, 2023):
All relevant variables are provided as ENV vars in the job or using the .env file. The proxy stuff of couse being in the .env since it applies to all jobs/workflows.
With the same variables from my .env file set, it works as expected. If I were to unset the proxy ENV vars in my bash session, I get the same error as in the job.
@alex1701c commented on GitHub (Aug 10, 2023):
That sounds like you could do a patch :D
The way I understand it, I must build the project and register it as a runner. This is a some communication effort, because I may not change the runner config of projects within my organization, because they are managed by a different team.
But I could compile act locally and try it out that way.
@ChristopherHX commented on GitHub (Aug 10, 2023):
No, there are binaries under releases.
github-act-runner configure https://github.com/actions --token ??? --traceis enough to see if it fails to connect or to register.But you can skip that, because the go-git works on your end.
Hmm, but this would mean your proxy works with go-git, but act does the same thing to clone.
Since go-git works out of box without having such workaround, why would act not? It basically use the same api as the go-git example.
I'm confused about inconsistent behavior of go-git you have described
Do you have the proxy env variables exported to the act cli like you have for the go-git example? (the content of .env or cli args don't matter)
@alex1701c commented on GitHub (Aug 10, 2023):
I tried out some other ideas and in the end it works in case I am in a shell as sudo. If I were to say "sudo ../act -j myjob", it does not work.
The problem: If I run sudo, the env variables are not passed in to the created process.
sudo printenvdoesn't yield the proxy settings I have in my user or root bashrc. Meaning I have to start a shell first.Though it seems off to me that the .env file is ignored here. Or rather, it is only used by the defined jobs/steps, but not the act executable. Or is this the expected behavior?
@github-actions[bot] commented on GitHub (Feb 7, 2024):
Issue is stale and will be closed in 14 days unless there is new activity