Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile should build from alpine instead of scratch #770

Closed
xibz opened this issue Dec 1, 2021 · 5 comments
Closed

Dockerfile should build from alpine instead of scratch #770

xibz opened this issue Dec 1, 2021 · 5 comments

Comments

@xibz
Copy link

xibz commented Dec 1, 2021

Hello! So my team and I are using the credential_process feature in the AWS SDK for Go, and this feature allows users to specify their own way of getting credentials through the ~/.aws/credentials file. However, the AWS SDK for Go expects sh to be present in PATH. However, scratch does not have sh. This makes the feature not usable at all with the aws-otel-collector which is a really odd experience when using AWS credentials files.

What I would love to see is either copying sh to the scratch workspace or just use alpine all together

@anuraaga
Copy link
Contributor

anuraaga commented Dec 1, 2021

Thanks @xibz - for various reasons we would like to stick with scratch if possible but this seems like an important use case to me. I have filed https://github.com/aws/aws-sdk-go/issues/4193 as it appears to be a gap in the SDK itself, there doesn't seem to be a reason to limit credential_process to environments that have a shell installed. If that got fixed and we updated, would that solve your issue?

@xibz
Copy link
Author

xibz commented Dec 1, 2021

@anuraaga Yep! That works as well!

@sethAmazon
Copy link
Member

@anuraaga may I close this ticket?

@anuraaga
Copy link
Contributor

anuraaga commented Jan 4, 2022

@xibz Unfortunately I don't think we will be changing our base image just for credential_process. From the linked issue you seem to have a (too tedious) workaround for now so are you comfortable closing this in favor of the SDK issue?

@xibz xibz closed this as completed Jan 4, 2022
@xibz
Copy link
Author

xibz commented Jan 4, 2022

Thanks! Went ahead and closed as the SDK should definitely address this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants