You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- FIX: Bandaid for Crashlytics [#944](https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/944) ([#1376](https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1376)), thanks to [Rogers George](https://github.com/ceramicatheist)
- NEW: tvOS push support ([#1375](https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1375)), thanks to [Thomas Kollbach](https://github.com/toto)
- FIX: Class properties ([#1400](https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1400)), thanks to [Thomas Kollbach](https://github.com/toto)
- FIX: Upgrade ParseFacebookUtils dependency to Facebook SDK v5.x ([#1411](https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1411)), ([#1424](https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1424)) thanks to [Herrick Wolber](https://github.com/rico237),[Darren Black](https://github.com/drdaz)
- FIX: Upgrade ParseFacebookUtils dependency to Facebook SDK v5.x ([#1424](https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1424)) thanks to [Herrick Wolber](https://github.com/rico237) and[Darren Black](https://github.com/drdaz)
The reason will be displayed to describe this comment to others. Learn more.
@drdaz just wanted to let you know that the release is tied to a commit and not a pull request which I dont think will trigger Travis to build and trigger the publish script. I could be wrong though.
The reason will be displayed to describe this comment to others. Learn more.
... and I feel that begs the question, why is the simulator being used when testing Cocoapods at all? Once all the functional tests pass, the Cocoapods test is surely 'just' linting followed by perhaps a test-run installing the Parse pod to a project and building it.
I'd really like to know where these steps are defined. I've spent quite some time trying to find this without success.
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty new to this but I think I may have figured part of this out. @drdaz if you take a look in .travis.yml you'll see two stages. The first is for using jazzy to create and deliver API documentation. The second stage shows the following.
Now, looking right below our error we see the following:
[!] The spec did not pass validation, due to 1 error.
/Users/travis/.rvm/gems/ruby-2.4.5/gems/cocoapods-trunk-1.3.0/lib/pod/command/trunk/push.rb:127:in `validate_podspec'
/Users/travis/.rvm/gems/ruby-2.4.5/gems/cocoapods-trunk-1.3.0/lib/pod/command/trunk/push.rb:68:in `run'
/Users/travis/.rvm/gems/ruby-2.4.5/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
/Users/travis/.rvm/gems/ruby-2.4.5/gems/cocoapods-1.5.0/lib/cocoapods/command.rb:52:in `run'
/Users/travis/.rvm/gems/ruby-2.4.5/gems/cocoapods-1.5.0/bin/pod:55:in `<top (required)>'
/Users/travis/.rvm/gems/ruby-2.4.5/bin/pod:23:in `load'
/Users/travis/.rvm/gems/ruby-2.4.5/bin/pod:23:in `<main>'
/Users/travis/.rvm/gems/ruby-2.4.5/bin/ruby_executable_hooks:24:in `eval'
/Users/travis/.rvm/gems/ruby-2.4.5/bin/ruby_executable_hooks:24:in `<main>'
Script failed with status 1
failed to deploy
Which means the error is coming during the bundle exec pod trunk push Parse.podspec --verbose. Which I think means that this the build script that gave us the simulator error isnt something from our files but built into our command to build and push the new release.
I was looking back into the travis build history and it seems on this build for release 1.17.2 that we got the error xcodebuild: error: unreadable input 'OS:11.2,name=Apple TV 1080p' at end of value for option 'Destination' which was fixed by updating the xcodebuildtools. Looks a little familiar right? In that situation the xcodebuild tools wasnt up to date with the version of cocoapods we where using.
I think our situation may be the exact opposite. I think this may be one of two things.
the version of cocoapods may not working with the version of xcodebuildtools. So when we run bundle exec pod trunk push Parse.podspec --verbose cocoapods internal scripts are causing the error.
The version of fourflusher we are running is out of date. The line that lead to the error we recieved is /Users/travis/.rvm/gems/ruby-2.4.5/gems/fourflusher-2.0.1/lib/fourflusher//find.rb:106:in "usable_simulators". Now I'm not entirely sure what controls which version we are using. I imagine that, judging by the file structure on each error aka .rvm/gems/ruby-2.4.5/gems/ that this might be dictated by the ruby version which is determined by the .ruby-version file.
Now we have to update everything for iOS and iPad OS 13 anyway. So we have two options.
Try messing around with the ruby version and try to get this release out.
Just go ahead and update everything(cocoapods, xcodebuildtools, ruby etc...) to the newest versions to prep ourselves for building what I assume will be 1.18.0 for iOS 13.
I'd love to know your guys thoughts.
UPDATE:
I think I just figured the problem. I check the ruby version on Mojave and by default it uses 2.3.7 which is LOWER than what we are using. So it cant be that. This got me thinking about the line gem install bundler. I guess I never thought about it before but I looked and sure enough we have a Gemfile. Which controls what gem versions we use . My guess is that cocoapods has fourflusher as a dependency which looks for simulator versions which isn't compatible with the verion of xcodebuildtools we use that was updated during last release.
The reason will be displayed to describe this comment to others. Learn more.
@TomWFox whats the best way to go about working on this? I'd fork it and do pull requests but I don't think that will trigger the release scripts to run. I'd hate to just do a bunch of commits directly to the main branc. Can I edit a commit over and over till the build passes somehow. Do commits need approval? Will it trigger builds prior to merging? Not sure how that works. Looking at the travis file:
on:
tags: true
all_branches: true
This would lead me to believe that working on a separate branch should still trigger the build script. But I'm not sure if thats true if the failing deployment of a release is on the main branch. I wish I could get started working on something but I dont seem to have the ability to create branches or anything on this repo.
The reason will be displayed to describe this comment to others. Learn more.
Wow, lots of digging going on here. I like it! I’m still trying to unpack and understand your findings.
But about whether to skip this release and go to 1.18.0 or not, I think that depends on the timeframe for getting the 1.18.0 changes ready. The SDK has been out of commission for Cocoapods users for a really long time now; if those 1.18.0 changes can be ready really soon, then it makes sense to skip. Otherwise I think we should try to get this one out the door, assuming of course that we’re just a few tweaks away.
The reason will be displayed to describe this comment to others. Learn more.
Is manually releasing this version to Cocoapods out of the question btw? This looks entirely like an infrastructure / environment issue at this point, so we could potentially just focus on getting the release mechanics working again for the next release if we trust that the tagged release is functionally good.
The reason will be displayed to describe this comment to others. Learn more.
@drdaz manually releasing would be a @TomWFox question. In terms of updating the build environment I've been busting my butt all night and almost got it done. I got it building right now but actually the only thing I have left is errors from a failed XCTest...not from the build itself. You may know your way around a bit better and may know how to solve it. My pull request can be found here.
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't say a manual release is out of the question, not something I've done before, I could give one of you access to the pod if you want to try that.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drdaz just wanted to let you know that the release is tied to a commit and not a pull request which I dont think will trigger Travis to build and trigger the publish script. I could be wrong though.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@noobs2ninjas Thx for the heads up. I did get a mail from Travis saying Cocoapods had failed on the the tagged release.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With @drdaz on this the right builds were started but the cocoa pods one failed - not sure how to fix yet
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TomWFox Ill take a look.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we go.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to decide if this is internal issue with Travis or if this is a xcodebuild error
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be recreated locally by running
bundle exec rake test:cocoapods. So it's not Travis specific.But I honestly can't see where the 'ios' value is coming from.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... and I feel that begs the question, why is the simulator being used when testing Cocoapods at all? Once all the functional tests pass, the Cocoapods test is surely 'just' linting followed by perhaps a test-run installing the Parse pod to a project and building it.
I'd really like to know where these steps are defined. I've spent quite some time trying to find this without success.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty new to this but I think I may have figured part of this out. @drdaz if you take a look in .travis.yml you'll see two stages. The first is for using jazzy to create and deliver API documentation. The second stage shows the following.
Which means it should simply be running the publish script located in the Scripts folder which simply says
Now, looking right below our error we see the following:
Which means the error is coming during the
bundle exec pod trunk push Parse.podspec --verbose. Which I think means that this the build script that gave us the simulator error isnt something from our files but built into our command to build and push the new release.I was looking back into the travis build history and it seems on this build for release 1.17.2 that we got the error
xcodebuild: error: unreadable input 'OS:11.2,name=Apple TV 1080p' at end of value for option 'Destination'which was fixed by updating the xcodebuildtools. Looks a little familiar right? In that situation the xcodebuild tools wasnt up to date with the version of cocoapods we where using.I think our situation may be the exact opposite. I think this may be one of two things.
the version of cocoapods may not working with the version of xcodebuildtools. So when we run
bundle exec pod trunk push Parse.podspec --verbosecocoapods internal scripts are causing the error.The version of fourflusher we are running is out of date. The line that lead to the error we recieved is
/Users/travis/.rvm/gems/ruby-2.4.5/gems/fourflusher-2.0.1/lib/fourflusher//find.rb:106:in "usable_simulators". Now I'm not entirely sure what controls which version we are using. I imagine that, judging by the file structure on each error aka.rvm/gems/ruby-2.4.5/gems/that this might be dictated by the ruby version which is determined by the.ruby-versionfile.Now we have to update everything for iOS and iPad OS 13 anyway. So we have two options.
I'd love to know your guys thoughts.
UPDATE:
I think I just figured the problem. I check the ruby version on Mojave and by default it uses 2.3.7 which is LOWER than what we are using. So it cant be that. This got me thinking about the line
gem install bundler. I guess I never thought about it before but I looked and sure enough we have a Gemfile. Which controls what gem versions we use . My guess is that cocoapods has fourflusher as a dependency which looks for simulator versions which isn't compatible with the verion of xcodebuildtools we use that was updated during last release.4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TomWFox whats the best way to go about working on this? I'd fork it and do pull requests but I don't think that will trigger the release scripts to run. I'd hate to just do a bunch of commits directly to the main branc. Can I edit a commit over and over till the build passes somehow. Do commits need approval? Will it trigger builds prior to merging? Not sure how that works. Looking at the travis file:
This would lead me to believe that working on a separate branch should still trigger the build script. But I'm not sure if thats true if the failing deployment of a release is on the main branch. I wish I could get started working on something but I dont seem to have the ability to create branches or anything on this repo.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flovilmart I know you are pretty busy and are taking a break from this but if you had a minute or two to weigh in we would be eternally grateful.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have write access to this repo to, so you should be able to create new branches.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, lots of digging going on here. I like it! I’m still trying to unpack and understand your findings.
But about whether to skip this release and go to 1.18.0 or not, I think that depends on the timeframe for getting the 1.18.0 changes ready. The SDK has been out of commission for Cocoapods users for a really long time now; if those 1.18.0 changes can be ready really soon, then it makes sense to skip. Otherwise I think we should try to get this one out the door, assuming of course that we’re just a few tweaks away.
What's your feeling on the timeframe?
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is manually releasing this version to Cocoapods out of the question btw? This looks entirely like an infrastructure / environment issue at this point, so we could potentially just focus on getting the release mechanics working again for the next release if we trust that the tagged release is functionally good.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drdaz manually releasing would be a @TomWFox question. In terms of updating the build environment I've been busting my butt all night and almost got it done. I got it building right now but actually the only thing I have left is errors from a failed XCTest...not from the build itself. You may know your way around a bit better and may know how to solve it. My pull request can be found here.
4439781There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't say a manual release is out of the question, not something I've done before, I could give one of you access to the pod if you want to try that.