I've added integration tests for published repositories. I also refactored the integration tests to remove the unnecessary if [ $? -ne 0 ] checks since -e will already catch non-zero return codes and to print out the failed test case.

@hypnoglow Anything I can do to move this PR along?

any possible movement on this? i could also really use this functionality.

@jgangemi Until this is merged, you're welcome to use my forked build:

helm plugin install https://github.com/steven-sheehy/helm-s3.git --version v0.9.0

@steven-sheehy awesome, thanks!

what's the behavior if i still want to access via s3? will both protocols work to read the charts or am i locked into one or the other.

@jgangemi Nope, you can use both concurrently, even from the same client. Just add the s3 and http as separate repos via helm repo add. The s3 repo can be used for read/write while the http can do reads.

@steven-sheehy awesome, thanks again!!

hey @steven-sheehy, you didn't touch anything w/ the push that would have affected * being resolved, eg:

helm s3 push --dry-run target/* repo

this used to work in an older version and doesn't ask of 0.9.0

My changes shouldn't affect the issue you're experiencing. * is expanded by bash not the s3 plugin. But helm s3 push [<flags>] <chartPath> <repo> doesn't take multiple charts paths so if bash happened to expand to multiple paths it wouldn't work.

weird b/c this used to work and helm lint charts/* earlier in the script has no issues. i'm sure i can change the script figure out the dirname.

thanks for responding and also doing this work, it saved me from having to figure out a hacky solution.

@hypnoglow can we merge this pr

@hypnoglow is this going to be merged? it's been some months now

@steven-sheehy - do you have your fork hosted anywhere that I can move over to? This PR looks abandoned...

Can this or #56 be merged? I use the plugin to publish the charts to a s3 bucket, which is then hosted by a cloudfront distro, hence I had to hack the index.yaml:

     urls:
-    - s3://thebucketname/fspython-0.1.0.tgz
+    - fspython-0.1.0.tgz

I don't want to spend time fixing the conflicts (which are not trivial) unless there's some indication the PR has the possibility of being reviewed and accepted.

@hypnoglow care to comment?

Also - I think this can be simplified, by having the list in the url element only list the archive name - i.e. without the protocol&host prefix - that worked for me - and they are resolved relative to the repo given.