[Tooling] Make pod trunk push be --synchronous, to fix issue when releasing both pods together
#1391
Conversation
To prevent the Editor pod to fail to be pushed to trunk if the Aztec pod it depends on hasn't propagated through the CDN yet
AliSoftware
changed the title
pod trunk push be --synchronous — to fix issue when releasing both pods together
AliSoftware
changed the title
pod trunk push be --synchronous — to fix issue when releasing both pods togetherpod trunk push be --synchronous, to fix issue when releasing both pods together
|
I noticed CI has been waiting for almost 12 hours. Not surprising given it's configured to run on Xcode 13 😳 
Looking at upgrading now... |
> Non-'@objc' instance method in extensions cannot be overridden; > use 'public' instead
Ideally, this should be removed once the warnings have been addressed
|
It seems like the test failures are due to the "Allow Paste" System Prompt—which now appears on the simulator in more recent iOS versions—during the copy/paste-related tests. @geriux @mokagio can I let you look at those failures? There's probably a way in XCTest to catch those during a UITest (maybe PS: While taking a quick look at the workspace I noticed that the build settings are still set to I also noticed that all the methods around manipulating and converting between |
2f50d83 bumps the target to iOS 12, which is the minimum supported by Xcode 15. The warnings remain, I added |
🤔 @jkmassel addressed this in #1377 by making the pasteboard injectable during unit testing. When I merged the latest As far as I can tell, the remaining tests failures at the custom
|
…' into mokagio/xcode-15.3
I don't see that |
@mokagio This should fix the `testPaste{Image,Video}WithoutFormatting` test failures. - I have searched the code for `decodeObject(forKey` occurrences and confirmed there wasn't any left - But I have not triple-checked that *every* custom subclass of anything we might encode in our `NSAttributedString` attributes have had `+supportsSecureCoding` redefined Indeed, apparently, **even if** the parent class already overrides it to return `true`, subclasses which override `init?(coder:)`/`encode(with:)` from their parent class need to also re-override `+supportsSecureCoding`. I've added the overrides in classes that I've modified, but there may be more classes that might not be covered by our unit tests around archiving/pasting but would still require it to be added? So would be worth making another pass to be sure we didn't forget any,
…inText` Since newer versions of iOS use this new `public.utf8-plain-text` UTI instead of `public.plain-text` like in previous OS versions.
This reverts commit 5c3004b, because I'm not convinced that's a good idea. We should double-check that **not** having `+supportsSecureCoding` declared on this subclass doesn't make it fail to be copy/pasted (i.e. archived/unarchived)—like similar cases happened when running Aztec tests. Or if we need `+supportsSecureCoding`, we need to find a way to override/redefine it across module boundaries…
Fix - Shortcode test
This is in line with our Buildkite/YML pipeline standard.
Why?
To prevent the Editor pod to fail to be pushed to trunk if the Aztec pod it depends on hasn't propagated through the CDN yet
Fixes the issue raised in this Slack thread: p1711026617605489-slack-CC7L49W13 cc @geriux
Testing
It's gonna be difficult to test the change on this repo without actually doing a new version of the Aztec and Editor pods.
The new ability of
publish_podto accept a--synchronousflag has already been tested as part of the Gravatar-iOS-SDK repo (which had a similar issue of co-dependant pods having to be released together), so I think we should be good though.So I say we can probably trust that it will work as expected like it did for the Gravatar repo, and I'm counting on the next dev who will have to make a new version of these pods to let us know if it ends up still not working.