Support testing without AWS secrets about awss3.jl HOT 6 CLOSED

Yeah, I don't have the time for that either. I'll just blacklist the package.

from awss3.jl.

The CI runs on a public AWS account provided by Invenia so we can do some integration testing for uploading, deleting, etc. objects.

If these secrets were added into PkgEval would that resolve the issue?

from awss3.jl.

If these secrets were added into PkgEval would that resolve the issue?

No, adding secrets (or other environmental information) to PkgEval on a per-package basis is not a scalable solution.

from awss3.jl.

If these secrets were added into PkgEval would that resolve the issue?

No, adding secrets (or other environmental information) to PkgEval on a per-package basis is not a scalable solution.

I'm not quite sure what the path forward is here in that case. We need to limit access to the AWS account, but still be able to test the package concretely.

I would not want to add in special code checking for PkgEval env vars and restructuring tests to have it work as this is not a dependency of this package.

We could create a public bucket in the account and place some objects in there, restructure tests to separate ones which do and do not require credentials. But that limits things to read only operations and does not seem value.

from awss3.jl.

I would not want to add in special code checking for PkgEval env vars and restructuring tests to have it work as this is not a dependency of this package.

You only need to check an environment variable. Why is that problematic? It's generally a good thing that registered, public packages can be tested without special set-up.

Alternatively, CloubBase.jl's minio wrapper could be used to create a public, S3-compatible environment, e.g., https://github.com/JuliaLang/BugReporting.jl/blob/00d09eede70ec9e3784e4f83ac26d338460fff6b/test/rr.jl#L104-L116

Ultimately though, I don't really care about AWSS3.jl's PkgEval-compatibility, so feel free to close. The only disadvantage is that this package won't be considered when testing for upstream Julia changes.

from awss3.jl.

You only need to check an environment variable. Why is that problematic? It's generally a good thing that registered, public packages can be tested without special set-up.

IMO, this package as well as AWS.jl and others are a bit more unique where if you're using them there's somewhat of an expectation that you have AWS credentials present. Although they do support credential-less requests, as part of testing you would want to test that your changes and nightly runs check everything.

Alternatively, CloubBase.jl's minio wrapper could be used to create a public, S3-compatible environment, e.g., https://github.com/JuliaLang/BugReporting.jl/blob/00d09eede70ec9e3784e4f83ac26d338460fff6b/test/rr.jl#L104-L116
Ultimately though, I don't really care about AWSS3.jl's PkgEval-compatibility, so feel free to close. The only disadvantage is that this package won't be considered when testing for upstream Julia changes.

Using MinIO would work, could refactor this to:

1. Run tests against MinIO
2. If credentials are present, run them on AWS

Personally I do not have the time to make these currently, if you make the PR though I can review though. Honestly this package really needs to be re-written anyways so I'm not too concerned about its current state that much.

from awss3.jl.