Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

[ios] Publish nightly build #8337

Merged
merged 1 commit into from
Mar 11, 2017
Merged

[ios] Publish nightly build #8337

merged 1 commit into from
Mar 11, 2017

Conversation

friedbunny
Copy link
Contributor

@friedbunny friedbunny commented Mar 10, 2017

Fixes #4196. Uploads a nightly build to s3 and makes it available via a special podspec.

  • Dynamic framework, stripped release build only for now.
  • Piggy-backs on @kkaefer’s binary size metrics Bitrise workflow that already runs nightly.
  • Uploads both to a date-versioned file and overwrites a stable URL file.
  • Adds a Mapbox-iOS-SDK-nightly-dynamic podspec that points to the latest nightly.

Use this line in your podfile to test this branch:

pod 'Mapbox-iOS-SDK-nightly-dynamic', :podspec => 'https://raw.githubusercontent.com/mapbox/mapbox-gl-native/fb-publish-nightly/platform/ios/Mapbox-iOS-SDK-nightly-dynamic.podspec’

To-do

  • Update this repo’s install/developing documentation with usage instructions.
  • Create new Bitrise workflow with Slack notifications, etc.

/cc @mapbox/mobile

@friedbunny friedbunny added build iOS Mapbox Maps SDK for iOS labels Mar 10, 2017
@friedbunny friedbunny added this to the ios-v3.5.0 milestone Mar 10, 2017
@friedbunny friedbunny self-assigned this Mar 10, 2017
@friedbunny friedbunny changed the title [ios] Add nightly build infrastructure [ios] Publish nightly build Mar 10, 2017
@friedbunny
Copy link
Contributor Author

Podspec URL will need to be updated to point to an iOS tag or some stable branch — it points to the current release branch now, as that’s the target of this PR.

@friedbunny
Copy link
Contributor Author

One potential pitfall of piggy-backing on the binary size metrics workflow is that we may not be willing/able to switch the branch of that workflow to point at the current release branch. Will that be an issue, @kkaefer?

Copy link
Contributor

@kkaefer kkaefer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're currently at ~25 min build runtime, so adding publishing should keep this well within the build timeout.

GENERIC_NIGHTLY_FILENAME="mapbox-ios-sdk-${PUBLISH_VERSION}.zip"
aws s3 cp \
s3://mapbox/$REPO_NAME/ios/builds/${ZIP} \
s3://mapbox/$REPO_NAME/ios/builds/${GENERIC_NIGHTLY_FILENAME} --acl public-read
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of copying over, can we create a link on S3 that points to the most recent version?

Copy link
Contributor Author

@friedbunny friedbunny Mar 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far as I can tell, s3 doesn’t support symlinks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object-level redirects look like they're perfectly suited for this too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it may be possible to create a placeholder file and then the s3 API could be used here to set up a redirect to the latest version by updating the metadata of the placeholder with x-amz-website-redirect-location.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be ideal — I’ll look into setting up a redirect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn’t make redirects work — we’re not strictly a “website” and aws is simply passing the x-amz-website-redirect-location header in GET requests, returning HTTP 200 and a blank file instead of HTTP 301 and the redirected file.

$ aws s3api put-object --bucket mapbox --key mapbox-gl-native/ios/builds/mapbox-ios-sdk-nightly-dynamic.zip --acl public-read --website-redirect-location /mapbox-ios-sdk-nightly-dynamic-2017-03-09.zip
$ curl -I -L https://mapbox.s3.amazonaws.com/mapbox-gl-native/ios/builds/mapbox-ios-sdk-nightly-dynamic.zip 
HTTP/1.1 200 OK
x-amz-id-2: Ub2UZ8qnAymsFa8eQUxPQZakb9Pwfb1TspVyl1kvulVT32uN6oZZMv2pO13eKiA9B5yPoxQMSig=
x-amz-request-id: A66C36AF51BB9C8E
Date: Fri, 10 Mar 2017 20:50:27 GMT
Last-Modified: Fri, 10 Mar 2017 20:50:23 GMT
ETag: "d41d8cd98f00b204e9800998ecf8427e"
x-amz-website-redirect-location: /mapbox-ios-sdk-nightly-dynamic-2017-03-09.zip
Accept-Ranges: bytes
Content-Type: application/zip
Content-Length: 0
Server: AmazonS3

Copy link
Contributor Author

@friedbunny friedbunny Mar 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm, HTTP 200 appears to be the intended behavior for this endpoint, per this thread:

The redirection functionality is only available for S3 static websites, which unfortunately means that you are seeing the intended behavior. A request served via the usual S3 endpoint will result in a response with the x-amz-website-redirect-location header, while the S3 website endpoint returns an HTTP redirect. Changing the origin to mybucketname.s3-website-us-east-1.amazonaws.com instead of using the bucket directly can theoretically solve the problem.

Hitting a website endpoint confirms we’re not set up as a website on s3. Configuring this bucket as a static website is more than I want to do to get this redirect working.

@kkaefer
Copy link
Contributor

kkaefer commented Mar 10, 2017

@friedbunny Ideally, the binary size metrics build will always run on master, not on other branches.

@@ -85,6 +85,14 @@ To test pre-releases and/or betas, you can reference the pre-release like so in
pod 'Mapbox-iOS-SDK', podspec: 'https://raw.githubusercontent.com/mapbox/mapbox-gl-native/<insert branch or tag>/ios/Mapbox-iOS-SDK.podspec'
```

##### Testing nightly releases with CocoaPods

To test a nightly dynamic framework build, use this line to your Podfile:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix the typo here.

@friedbunny
Copy link
Contributor Author

Ideally, the binary size metrics build will always run on master, not on other branches.

OK, then I think we’ll want to create another nightly workflow that can have its branch retargeted for releases.

Copy link
Contributor

@boundsj boundsj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really glad this is happening! I don't have a strong opinion about the redirect (instead of symlink) optimization but it does seem like it may be possible.

In general, I think it'd make sense to target this PR at master instead of the release branch and use the nightly for a "nightly mainline?" build.

An additional, similar bitrise workflow could be set up to create nightly builds "nightly prerelease?" for our longer running major / minor release branches.

If we think that having two nightlies would be overkill then we could just do the second option only and manually point it back and forth from master <-> release branch as required.


```rb
pod 'Mapbox-iOS-SDK-nightly-dynamic', podspec: 'https://raw.githubusercontent.com/mapbox/mapbox-gl-native/release-ios-v3.5.0-android-v5.0.0/ios/Mapbox-iOS-SDK-nightly-dynamic.podspec'
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand how this would work, if a developer uses this, then they will reach the .podspec file on this temporary release branch on GitHub but that podspec has an s3 URL that points at an archive of a build from the master branch (and that's assuming that zip archive does exist, which I don't think it would, until this change is merged back to master)

GENERIC_NIGHTLY_FILENAME="mapbox-ios-sdk-${PUBLISH_VERSION}.zip"
aws s3 cp \
s3://mapbox/$REPO_NAME/ios/builds/${ZIP} \
s3://mapbox/$REPO_NAME/ios/builds/${GENERIC_NIGHTLY_FILENAME} --acl public-read
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it may be possible to create a placeholder file and then the s3 API could be used here to set up a redirect to the latest version by updating the metadata of the placeholder with x-amz-website-redirect-location.

@friedbunny friedbunny force-pushed the fb-publish-nightly branch 3 times, most recently from d23c87e to f4d890c Compare March 10, 2017 23:41
@friedbunny friedbunny changed the base branch from release-ios-v3.5.0-android-v5.0.0 to master March 10, 2017 23:42
@friedbunny
Copy link
Contributor Author

Retargeted this against master and changed the docs to point there. I think we should merge this and then add a release branch nightly later, if we find that we want one.

@friedbunny friedbunny removed this from the ios-v3.5.0 milestone Mar 11, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
build iOS Mapbox Maps SDK for iOS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants