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

configure aws-spi-pekko-http integration tests in nightly builds #832

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

jtjeferreira
Copy link
Contributor

As discussed in #827 (comment), this PR configures aws-spi-pekko-http integration tests.

I understand that S3 module integration tests are setup in a different way (using @DoNotDiscover and explicitly calling org.scalatest.tools.Runner) , but I don't want to touch for now.

I changed the way credentials are passed to use environment variables. I did this, because for the aws-spi-pekko-http tests the credentials cannot be configured using JVM system properties, but both tests support environment variables as part of the default credential provider.

@jtjeferreira
Copy link
Contributor Author

@pjfanning thanks for running the workflows. For some reason the secret is not being properly propagated.

If I look into https://github.com/apache/pekko-connectors/actions/runs/11044846930/job/30681466278, I see that the secret is masked as expected:

sbt \
  -Dpekko.connectors.s3.aws.credentials.provider=static \
  -Dpekko.connectors.s3.aws.credentials.access-key-id=*** \

However in https://github.com/apache/pekko-connectors/actions/runs/11049659282/job/30695897761?pr=832 it is empty:

env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.422-5/x64
    JAVA_HOME_8_X64: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.422-5/x64
    AWS_ACCESS_KEY_ID: 

I don't have much experience with github actions...

@pjfanning
Copy link
Contributor

It looks like there are possibly some restrictions set up so that the access key secret can not be used as an env variable. I'll raise an issue with the ASF Infra team to see if they can give some guidance. This could take a while.
Can you add an 'assume' section to any tests that need the env variables and have the assume section check if the env variable is non-empty? This would mean that the test is skipped if the env variable is not there.

@jtjeferreira
Copy link
Contributor Author

@pjfanning I reverted all my changes to make sure the secrets can be accessed in a PR. If it works, I will progress from there...

@jtjeferreira
Copy link
Contributor Author

@pjfanning I reverted all my changes to make sure the secrets can be accessed in a PR. If it works, I will progress from there...

As I suspected the secrets cannot be accessed in a PR. Can that be changed?

@pjfanning
Copy link
Contributor

@jtjeferreira looks like you were right - the secrets seem not to work when you are building for a CI

Do you want to remove all the changes and add back the env vars? I can merge it and run the Nightly Build CI job?

The env vars seem to be:

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

@pjfanning
Copy link
Contributor

The ASF Infra team answered and said that GitHub forks of the main project don't have access to the secrets.

In theory, I could create a branch on the main project and create a PR off of it. Let me try that.

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

Successfully merging this pull request may close these issues.

2 participants