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

Add support for alternate download endpoints? #47

Open
dlethin opened this issue Jan 19, 2018 · 1 comment
Open

Add support for alternate download endpoints? #47

dlethin opened this issue Jan 19, 2018 · 1 comment

Comments

@dlethin
Copy link
Contributor

dlethin commented Jan 19, 2018

I have a need for all the S3_*_OUTPUT_PATH env variables returned with a different s3 endpoint then is used for uploading. The use case for this that the s3 bucket we use to store our IPAs and build artifacts are front-ended by AWS Cloudfront configured with WAF. This provides us the ability to lock down public http access to our artifacts with a set of rules such as limiting by remote ip address.

The action currently supports supplying an optional endpoint, but that wasn't working for us, as we do not setup any policies in IAM to allow PUTs to cloudfront ( I'm not even sure how that works or is supported).

I have a fork with a commit which resolves the problem for us. Would you consider merging it if i submit a PR?

Thanks.


BTW, Thanks for sharing this plugin/code. I had written my own code in our build over a year ago for supporting OTA app downloads when we were hosting our artifacts in a different repository. When we recently needed to switch to s3, I came across your plugin and was not only able to upload my artifacts to s3, but I was able to rip out all my code for generating the html and plist metadata for supporting adhoc OTA installs. Makes my Fastlane so much cleaner.

@andris-zalitis
Copy link

The use case for this that the s3 bucket we use to store our IPAs and build artifacts are front-ended by AWS Cloudfront configured with WAF. This provides us the ability to lock down public http access to our artifacts with a set of rules such as limiting by remote ip address.

We had a similar situation. Instead of changing the plugin itself though, we used custom template files where we replaced the hostnames in the URLs. I.e. something like this:

// s3_ios_version_template.erb
{
<% cdn_plist_url = plist_url.sub("our-private-bucket.s3.amazonaws.com", "our-public-access-cdn-endpoint.com") %>
<% cdn_ipa_url = ipa_url.sub("our-private-bucket.s3.amazonaws.com", "our-public-access-cdn-endpoint.com") %>
    "latestVersion": "<%= full_version %>",
    "updateUrl": "itms-services://?action=download-manifest&url=<%= url_encode(cdn_plist_url) %>",
    "plist_url": "<%= cdn_plist_url %>",
    "ipa_url": "<%= cdn_ipa_url %>",
    "build_number": "<%= build_num %>",
    "bundle_version": "<%= bundle_version %>",
    "release_notes": <%= release_notes.to_json %>
}

The same approach would go for html and plist templates.

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

2 participants