-
Notifications
You must be signed in to change notification settings - Fork 295
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
No such module 'PPRiskMagnes', continued #735
Comments
👋 Hi @eseay - I appreciate you opening this issue and bringing this to our attention again. It is definitely a weird one. So, we have a sample app that pulls in Braintree via SPM running on our CI (we have builds for both XCode 12.5 and XCode 13 beta). In the past few weeks/months we haven't seen this issue surface at all again. However, we will do our best to dig on this some more when we have the time. Will keep you posted when that happens! |
@scannillo Thanks for keeping it on your radar!
EDIT: Before rolling back, I decided to randomly try something that seemed completely unrelated to Braintree in particular, which appears to have resolved the issue. In our GitHub Actions workflows, we have a caching step that was taken directly from the actions/cache repository. The intent of this step is to theoretically speed up our workflows by removing the need to download all the packages from their remote locations and to rely on a download within GitHub Actions when possible.
The change is that I have removed this step from all of my workflows. The results:
Though it seems the solution required no changes to the BT integration, I thought it may be helpful to post this here for others, as I have only seen this cause issues with the BT framework, and since the caching step is officially promoted by GitHub, it seems like something that others might be doing. |
Hey @eseay - thanks so much for posting this and providing context for others to follow, that is super helpful. I am glad it is resolving your issue! I'm going to keep this issue open a few more days 1) to make sure it consistently resolves your issue and 2) so others can find it. Please do post if things change. |
@scannillo Unfortunately while it does seem to have greatly reduced the frequency of the issue, it seemingly has not eliminated it. We'll be moving all of our development to Xcode 13 in the next release cycle, so hopefully we may see improvement then. |
I have been tracking the issue for a year, it is not fixed. It has been broken since Xcode 12.0 b4! I do not think it will be anytime soon (I still hope :) ). See Xcode 13 release notes Could you go fully source code?
|
While I expect that distributing the source code of that framework may pose a some security implications, based on @simonpierreroy's note I do wonder if there is another way that we could go about integrating the framework. I obviously prefer to use Swift PM for all my dependencies, but I am willing to use an alternate approach - like download and manual drag+drop integration - if it means my builds will not fail on CI as frequently as they do. I've gotten to a (sad) point where now if I see a PR validation job has failed after 5 minutes, I just instinctively know it was because of PPRiskMagnes and just admin merge the thing to avoid having to wait for indefinite number of additional attempts until the job passes. |
v5.5.4: error: Missing package product 'PPRiskMagnes' (in target 'xxx' from project 'xxx') |
Hi @ikorich - if you think there's a bug or issue with that version, please open a separate GitHub issue. |
hi @scannillo , you can close ticket, updated dependencies and now it works |
@simonpierreroy - any updates on your end using v5.4.4? |
@scannillo Not yet, since FB77465707 in the Xcode 13 release notes acknowledged that any swiftPM target that depends on a XCFramework can break (since Xcode 12.0), and there is no work around possible! So by moving targets around, it may work by chance for some folks, but in our code base it will alway fail since we have a big build graph were the issue can be reproduced consistently, even with internal packages. I removed all usage of XCFrameworks in swiftpm targets in our codebase. For braintree, I built the full graph of dependencies as XCFrameworks and linked those to our main app directly, removing your swiftpm package. I have no hope that this 1 year old bug will be fixed anytime soon, but still I hope I am wrong. For now, I used swiftPM a lot in our code base, but banned XCframework dependencies in a swiftpm target (your exact use case). We can only use xcframeworks if linked to any app (even if distributed with swiftpm, but not used in a swiftpm target). Thank you for following up :) Please let me known if you will offer a version that does not require any pre build binary, or a version that pre-build binaries are not used in a swiftpm target. I would need to look at the latest version to see if xcframeworks are not needed to build swift pm targets ;) |
@scannillo Sorry - haven't looked at this in a minute. I ended up going with a workaround in the interim of just downloading the xcframeworks from this repo and manually integrating them. I will try again moving back to SPM. Stay tuned for updates! |
+1 to this. Happening here as well and it's really frustrating. Xcode 13.1 I may revert Braintree to be used through Cocoapods. SPM has been around for a while and it's our preferred option though. |
I'm also encountering this issue, happens only when running a CI build within my unit testing module on CircleCI, but I don't encounter it when I'm running the application locally via Xcode. |
This is normal, due to the bug mentioned here #735 (comment) , if your derived data is warm up, or if your machine compute a different build graph (parallelism), it may or may not fail. Plus, I think the latest version does not link properly the binary dependency on the swiftpm file. (Even if it will fail, dur the Apple |
I'm seeing this as well with every build, including with the latest |
👋 Hi everyone. This is more of an exploratory comment/question - The React to this comment with: |
v5.5.0 |
Again, there is nothing you can do about it! Apple claims a fix in Xcode 13.2b2 (the bug as been there since (Xcode 12.0). I will have to investigate soon. |
As @simonpierreroy said, this is from the Xcode 13.2 Release Notes.
I will be testing at the beginning of my next release cycle now that 13.2 appears to be available on GitHub Actions. |
Hi @eseay - thanks for updating this thread with that information. Please let us know if Xcode 13.2 resolves your issues! |
@scannillo you will need to fix the |
Hi, I am experiencing the same error: Error:
Bitcode is disabled in my project. It compiles correctly locally but when I run it on CI it fails. CI is using gitlab and they are self-hosted runners using the exact same version and configuration as I have in my local machine. |
That is normal! The package file has not been fixed for 13.2! #735 (comment) |
I also hit this issue on Xcode 13.2 with Braintree 5.5.0, on CI. |
Hi Simon. I don't think reverting that change is going to provide a fix here, as the way we have it structured now (including the binary dependency in the library target) is the intended use of binary dependencies via SPM according to Apple's docs. This seems to me that Apple still hasn't properly fixed this bug. |
Are there any workarounds? I am using Braintree Drop In and have the same issue on our CI Mac Mini, which builds using fastlane. |
@scannillo this is true, but you still need to |
Any update on this? @scannillo |
Any workarounds for this issue ? |
Hey all, I'm afraid I have to bump the issue since I've run into it as well. Some details: This is becoming a blocker for our efforts to have a single dependency manager in our project, so we hope it can be resolved soon. Thank you. |
@scannillo did you apply the fix that should fix it ? The fix: add an explicit dependency of the binary targets for modules where there is an import statement of that binary. |
Also bumped into this recently.
We got some suggestion that including For now, we just resorted to using the |
Here is the fix based on Xcode 13.2, it fixes a dependency graph issue introduced in Xcode 12.0 for binary targets in swiftPM. But even if the fix is there now in Xcode 13.2, you need to properly declare the dependency graph! @scannillo could we have a branch with the fix below in the image for us to try :) Please apply this idea for all the import of other binary targets. #735 (comment) |
Hello @simonpierreroy (and everyone else following this thread) - we've put up a test branch for this named Our CI is passing so the other package managers seem to be happy with this change. As we have not been able to replicate this error, would anyone (or everyone) that has run into this issue mind pulling in the branch and testing and letting us know the results? If this does work, we can get a release out with this change, if it does not resolve the issue, we'd be more than happy to continue troubleshooting. |
Thank you @jaxdesmarais. Good idea, let us see if this helps folks in the 🧵. I should work except if Apple has not really fixed the issue. I am happy to update my personal feedback ( |
@jaxdesmarais I have pulled in your branch, and I have since had 3 consecutive CI builds run successfully - no failures yet. Prior to these changes, it would fail on the first try. I think this looks promising! @simonpierreroy can you report back when you confirm this works for your project too? |
@eseay it will probably take make weeks before I can test… I will try definitely at some point. But I think there is no harm in merging this fix since it only add correctness to the swift package definition. Maybe other folks that had issues can try and report back. |
@jaxdesmarais the changes in |
We will check once on our end too. @jaxdesmarais Sorry to rush you, but do you have an ETA in mind ? |
@srikanth-vm - we hope to have a release with this change out this week, our UI tests are failing due to a backend service, so once that is resolved and our build is 🟢 we will merge the change and cut a release. I'll update the thread here as soon as it's released for everyone to pick up. |
We used |
Thank you all for testing! This has been released in version 5.6.3. |
This is amazing updating now |
Wonderful! @jaxdesmarais @scannillo thank you for working through this with us all! |
👋 Hey all - I am going to close this issue as several folks have indicated the fix in version 5.6.3 is resolving the initial reported issue. That said, if this creeps back up, please feel free to respond here and we'd be happy to reopen the issue and troubleshoot further. 🚀 |
Hello @mrazam110 - The errors you are seeing appear to be unrelated to the initial issue reported here. As a first step have you cleared derived data and cleaned (cmd + k) the Xcode project? If you are still running into errors, can you additionally share both the Xcode and Swift versions your project uses so I can attempt to reproduce? |
Integration Details (please complete the following information):
Describe the bug
First, I'll acknowledge that this bug has been discussed a handful of times and has been marked as resolved a handful of times as well, but this still seems to be happening. Related issues include but may not be limited to the following:
When building the app, occasionally within Xcode on our machines (this occurs to my team as well, not just me) but more commonly when running in CI, the build will fail with the following error:
/Users/runner/Library/Developer/Xcode/DerivedData/SCHEME-bdxyuxwdpsyvykcozvxottrpexnb/SourcePackages/checkouts/braintree_ios/Sources/PayPalDataCollector/Public/PayPalDataCollector/PPDataCollector.swift:1:8: no such module 'PPRiskMagnes'
referencing the line in
PPDataCollector
-import PPRiskMagnes
.To Reproduce
Reproducing this issue is kind of a funny situation. It's "hard to reproduce" because I cannot pinpoint the issue to any specific cause, but it "reproduces itself" frequently enough to be a pretty regular inconvenience in our build process. Worth mentioning as well, because of the way that macOS minutes are billed on GitHub Actions, these failed builds actually end up wasting money. When this fails in a CI job, I am normally able to circumvent the issue by re-running the job and hoping that the issue doesn't occur on that build. That said, I still do not think the presence of a semi-workaround is reason to consider this a non-issue.
As stated before, this occurs periodically when building. The move to Xcode 12.5.x and BT 5.4.3 as described in your docs mitigated the issue, but the issue still persists. Prior to updating our GitHub Actions to macOS 11 (enabling us to use Xcode 12.5), the last working version of Braintree I had been using for quite some time was v5.2.0.
Some additional information about the latest failure I encountered:
GitHub Actions Environment Info
Build Execution Outtakes (Abbreviated)
Expected behavior
Build does not fail due to missing module.
Hopefully the information provided can be some sort of help to the team in triaging and resolving the issue at hand. I am happy to provide as much information as I am able to, though what I have provided in this issue is as much as I know.
Thank you!
The text was updated successfully, but these errors were encountered: