-
-
Notifications
You must be signed in to change notification settings - Fork 877
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
ci: Remove publishing release assets #1745
Conversation
Thanks for opening this pull request!
|
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1745 +/- ##
=======================================
Coverage 64.41% 64.42%
=======================================
Files 200 200
Lines 23177 23177
=======================================
+ Hits 14929 14931 +2
+ Misses 8248 8246 -2 ☔ View full report in Codecov by Sentry. |
There 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.
Looks good, is this ready for merge?
This is ready for merge |
🎉 This change has been released in version 2.7.2 |
@dplewis @mtrezza after reviewing the conversation within PR #1741 I'm still not sure what exactly the motivation was to remove the assets following the I found having the Release assets very convenient. Especially in my current project where it is the only dependency, it's nice and simple to just download say the If removing the convenience of including the compiled builds from the asset section of the Release, then let's at least include some documentation as to what the best way would be to create this assets on our own. Seems like relevant documentation for manually compiling the SDK has also been removed from the README.md. Why? |
At the very least, maybe just publish |
@JohnCaccavale The main reason is because we only support installing via Swift Package Manager. Also the release assets couldn't compile on XCode 14+. It's highly recommend using SPM over a static framework. |
But we're on Xcode 15 now, why do we care about Xcode 14?
But I need to keep a copy of the framework in my |
Xcode 14+ meaning every version after 14 including 15. Feel free to try to get it to work. Warning this was an issue for years.
It's standard convention. Just give it a try after all it's just one dependency. |
Yes I've used Swift Package Manager, as I manage an SDK at my day job which I deploy via SPM. I've also spent my fair share of time in WWDC labs with members of that team working around some of the initial warts. It's not that I don't want to use a dependency manager, it's the fact that in this case I still need to include the framework in I'm fine with manually building the framework, but at the very least let's include some documentation in the README on doing such, so one easily knows what command to run, etc. What would your recommendation be on that? |
@JohnCaccavale Can you create a new issue for this? I don't want this conversation to get lost. The reason why this doesn't compile for XCode 14+ is because universal frameworks I actually started working on this a while ago. You can try this makefile https://github.com/dplewis/Parse-SDK-iOS-OSX/blob/universal-binary/Makefile |
@dplewis I'd be glad to take a look, I believe I have some notes regarding this laying around somewhere in my office. At work, I am building an XCFramework, being deployed as a referenced binary via SwiftPM from a private Git repo. I'll check my notes and look through that Makefile. I'm currently dealing with another issue at the moment, I am seeing similar behavior as reported in this Issue currently, #1771 which I'm in the process of trying to figure out whats going on. |
@dplewis my apologies for being a bit slow today. I just realized, if I statically link Parse to my command line utility, then that eliminates the need for having to keep the compiled version of the Parse Framework in the |
@JohnCaccavale No problem, I'm glad you got it working. |
* commit 'ef9b00de9eeeca7fddfe9439141f5141ff5dac02': (86 commits) chore(release): 3.0.0 [skip ci] ci: Fix release workflow (parse-community#1782) feat: Remove `ParseFacebookUtils` and `ParseTwitterUtils` (parse-community#1779) feat: Add `PFObject.isDataAvailableForKey` to check if data is available for individual key (parse-community#1756) ci: Bump ip from 2.0.0 to 2.0.1 (parse-community#1772) ci: Fix failing CI by pinning bundler version (parse-community#1778) refactor: Remove Carthage dependency (parse-community#1763) refactor: Remove OCMock Carthage dependency (parse-community#1754) ci: Run CI on Xcode 15 and macOS 13 (parse-community#1753) refactor: Update ruby dependencies (parse-community#1752) refactor: Remove framework builder for assets (parse-community#1751) chore(release): 2.7.3 [skip ci] fix: Compilation errors in `ParseLiveQuery` using `Starscream` 4.0.6 (parse-community#1749) docs: Add changelog note about missing assets (parse-community#1750) chore(release): 2.7.2 [skip ci] fix: Compilation errors `Undefined symbol` and `SystemConfiguration not found` on watchOS (parse-community#1748) ci: Remove publishing release assets (parse-community#1745) ci: Fix and build Starter Projects (parse-community#1744) chore(release): 2.7.1 [skip ci] fix: Compilation error on macOS `Undefined symbol: OBJC_CLASS$_PFProductsRequestHandler` (parse-community#1739) ...
New Pull Request Checklist
Issue Description
Removes publishing release assets from release. Users are still able to compile these assets themselves on Xcode < 14.
Closes: #1740
Approach
TODOs before merging