Add more debug statements

[michalfurmanek]

Describe the feature

Hello all,

I need your help with understanding log output that is throwing us an error:

##[debug]Result: '***'
##[debug]Loading env
Run aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ***
    aws-secret-access-key: ***
    aws-region: ***
    role-to-assume: ***
    role-duration-seconds: 1200
    role-skip-session-tagging: true
    audience: sts.amazonaws.com
::add-mask::***
::add-mask::***
Error: connect ETIMEDOUT 52.94.X.X:443

it's failing right after evaluating all secrets from GH. For sure this is some connectivity problem but we are trying to understand what is this address 52.94.X.X and why this script is trying to connect there? We are running on our self hosted runner on ec2 which already has proxy variables configured.

Is it possible to increase debug level to see in which part of the code it is failing?

Thanks

Use Case

whenever we are initializing new job on self hosted GH runner

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

[peterwoodworth]

Hey @michalfurmanek,

If you have specific places in mind where you think debug statements make sense to place, feel free to call them out. I think it would be great to have more debug statements if they can be helpful, we can look into that on our end too

If you'd like to debug yourself, feel free to fork this repo and clone it, install packages, add changes to the src/*.ts files, package with npm run package, and then push back to your fork and then run the action from your fork.

If you provide more specific reproduction steps, we can look to see if it's an issue on our end that needs fixing. We had to change how the proxy implementation works migrating from v2 to v3 due to migrating the JS AWS SDK to v3. I'm curious if you could also try v2 to see if that works

[michalfurmanek]

Thanks for you response @peterwoodworth. Looks like with v2 it worked without any problems.

[peterwoodworth]

Ok @michalfurmanek, thanks for the response. It seems then that there's some issue with how we've implemented the proxy with v3. Would you be able to provide details on how you setup your proxy on EC2 so I can try to reproduce with the setup you have?

[michalfurmanek]

sure - we have script that's located at /etc/profile.d/proxy.sh with following content and format:

export HTTP_PROXY=XXX
export HTTPS_PROXY=XXX
export NO_PROXY=XXX
export http_proxy=XXX
export https_proxy=XXX
export no_proxy=XXX

it's in user-data, so when instance is launched we're just executing source /etc/profile.d/proxy.sh

[RaviVadera]

Is there any update on this? Facing the same issue with v4 behind proxy.

[peterwoodworth]

I'm not a maintainer here anymore, @tim-finnigan this issue might need relabeling or merging with another issue (if there is a similar issue open, not sure)

[RaviVadera]

@peterwoodworth @tim-finnigan I would suggest changing the labels for the issue, this is a breaking thing from v2. So should be considered as bug / defect rather than feature request and maybe on high/urgent priority? We can't migrate to v4 which also adds support for node 20 required by GitHub Actions.

[tim-finnigan]

@RaviVadera could you elaborate on the breaking nature of this issue? I'm wondering if a new issue is necessary for what you're asking about. From what I can tell this issue is originally a request to add more debug statements.