-
Notifications
You must be signed in to change notification settings - Fork 174
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
Builds failing on Bitrise with stack Xcode 13.3.x (beta) #417
Comments
@MatyasKriz Have you seen any issues with the latest Xcode beta? |
Hey, @brandtdaniels. I haven't tried compiling nor running Cuckoo on the beta builds of Xcode. Not sure what the issue could be. |
Is there more info somewhere in the logs? My internet connection isn't stellar to download the Xcode beta just to find an issue. |
I didn't really see anything more in the logs |
Is it possible to switch to an earlier Xcode on Bitrise, or is this just a heads up that Cuckoo fails to run in Xcode 13.3 beta? I'll have to take a look at the missing CI in this project. |
We typically prepare for upcoming versions of Xcode/iOS as soon as they become available. We try to catch these issues proactively. This is sort of a heads up, but would also like to resolve this as we have nightly builds that run specs against the latest stacks (including betas) |
For me it is failing on lastest xcode |
My project is failing after updating Xcode, as well, but with signal 4.
Doesn't seem like adding |
Same problem here, usually, I would try my best to fix it, but it crashes without reason. |
Ok, after exploring why only some files were making the script crash. I found out that if the protocol defines a function without a label, it crashes.
|
It's the same for me. |
I'm also seeing the same issue after upgrading Xcode to 13.3 |
It seems that SourceKit has been updated. When parsing parameters without a label such as |
Hey everyone! Thanks a lot for the leads, especially @antoniocasero and @dongdonggaui for finding the issue. 🙂 I've verified that the problem is indeed because of the missing properties, though the name range isn't used, so I've just made it optional for now. I've merged and released the fix, please try it out and let me know if it helped. 🙂 |
Does it take time to propagate the release? The update isn't being picked up when trying to update the package on my end. |
Which package manager? |
Sorry, SPM |
I see, that's my bad. The change here is actually in the generator, not Cuckoo itself, but the binary hasn't been uploaded for some reason. I've fixed that, so now the newest one should get downloaded. 🙂 |
@MatyasKriz I'm getting this error message when trying to resolve packages:
|
@brandtdaniels hm, that must be the addition of OCMock, I'll see what I can do. In the meantime, as these changes are in the generator binary only, you can fallback to |
Can you clarify how 1.6.0 on SPM will pick up the new generator? I know there were some steps I took to manually copy some scripts/binaries into the project to get Cuckoo to work with SPM. |
The |
@ajpallares sorry to ping you in this issue, but do you happen to know how to work around the OCMock unstability? |
Hi @MatyasKriz, using cocoapods here, got the Cuckoo 1.7.0 release. It's working for me. Thank you very much for the fix. |
@MatyasKriz I'm afraid that a simple workaround is not possible. It looks like referencing a dependency using the commit hash or branch name) is considered an "unstable reference" by SPM. And a stable reference, i.e. a tag, can only depend on unstable references... (a better explanation here) This is, in fact, pointed out in the very OCMock repo, but which I did not see beforehand :( There might be a possible workaround for this, which involves having a local Swift Package which wraps the unstable package. I need to investigate this in depth. We might take advantage of the fact that we actually need to have the Swift wrapper Cuckoo+OCMock. Sorry for the inconvenience and I hope I can solve this soon using that workaround. |
@ajpallares thanks for the thorough analysis. 🙂 Don't worry about it, this kind of stuff happens. I'm glad you're here to help us push through. I'll release 1.7.1 without the SPM changes for now, so there's no pressure at all. |
@MatyasKriz It sounds like you're saying I don't need to do anything and the Bitrise build should just pick up the new generator binary. This doesn't seem to be the case. Can you clarify a little more how an older version of Cuckoo will pickup a new generator binary? |
@brandtdaniels Depending on how you call the |
Thank you. Bitrise starts clean every build, so I would assume that it would download the generator every time. I did just notice though that we have "cuckoo_generator" committed to our repository. Is having it committed good practice? with SPM? Locally, I deleted the cuckoo_generator and ran the specs to see if it would download a newer one and I got this error
|
To work with SPM, I had to download the latest |
@brandtdaniels I'd highly recommend against commiting binaries into the git repo. Every time you update a binary in git, it essentially doubles in size. I'd also suggest you delete the commits that added the binary in the first place. The problem you're facing is that there's no way for us to update your |
If you're using Git LFS (large file storage), you can check in the binaries (cuckoo generator etc) into your repo and mostly have constant size over time, which is not terrible. Aka if you upgrade cuckoo a few times, the overall repo / checkout size won't change. Git LFS only requires downloading the versions of the files (tracked by LFS) that are reachable from the commit you are checking out, not every delta in between like normal git tracked files. We (and possibly a lot of other Cocoapods users) 'vendor' the entire
Automatic tracking of large files in Git LFS is a highly requested feature (see git-lfs/git-lfs#282), but one fairly easily worked around with a little bit of scripting. |
@jgavris I don't know your setup and I assumed that the binary was not in LFS. Of course, if you want to keep the binary in the repo, it's your call. 🙂 |
It looks like the run script on master hasn't been updated in 2 years |
I see, time flies. 😅 Though the current version seems to work without problems. |
After removing the binary from the repo, and adding
|
Let's keep this issue closed and not ping all the other participants with debugging. The original issue has been fixed and now we just need to find out how to get your build script to correctly download the latest binary. Please open a new issue with some more information – if you run the |
@MatyasKriz This is not fixed, it's returning signal 9 on The code used to generate the mock is: "${PROJECT_DIR}/Scripts/cuckoo" --clean --download generate --testable "${PROJECT_NAME}" \
--output "${OUTPUT_FILE}" \ Results into:
|
Bitrise stack "Xcode 13.3.x (beta) on macOS 12.2 (Monterey)" is failing builds with the following error message
Recently included the following conditionals in the Cuckoo Run Script which seems to have no improvement
The text was updated successfully, but these errors were encountered: