Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CI builds are broken #2479

Closed
karliss opened this issue Nov 17, 2020 · 5 comments · Fixed by #2490
Closed

CI builds are broken #2479

karliss opened this issue Nov 17, 2020 · 5 comments · Fixed by #2490
Labels
CI Continuous integration High Priority This issue should be handled as soon as possible since it describes a major problem in Cutter
Milestone
2.0.0

Comments

@karliss
Copy link
Member

karliss commented Nov 17, 2020

Some of the last CI builds for pull requests are broken. Most likely due to changes in CI environment.

Examples:
travis macOS https://travis-ci.com/github/radareorg/cutter/jobs/440560066
windows https://ci.appveyor.com/project/radareorg/cutter/builds/36329032/job/2401ua3s839o96ct

In case of macOS looks like there are plenty of other people complaining about similar problem https://travis-ci.community/t/after-migrating-to-travis-ci-com-from-org-i-get-an-error-occurred-while-generating-the-build-script-on-macos/10578 There are various theories about cause and fixes, but seems like more likely that their build got fixed by randomly changing something. We have two similar macOS jobs one of which is failing, none of the properties mentioned in suggested fixes differ for them.
@karliss karliss added High Priority This issue should be handled as soon as possible since it describes a major problem in Cutter CI Continuous integration labels Nov 17, 2020
@karliss
Copy link
Member Author

karliss commented Nov 17, 2020 •
edited
Loading

As for the windows one shiboken fails to parse MSVC headers. I guess that MSVC got updated shiboken needs to be linked against newer Clang so that it can parse the new MSVC headers. This has happened a few times before. Sometimes it's possible to delay cutter deps rebuild by changing appveyor image config. Need to compare the versions in logs to confirm this theory. Also need to check how cutter-deps handle Clang.

@karliss karliss mentioned this issue Nov 18, 2020
Merged
3 tasks
@karliss
Copy link
Member Author

karliss commented Nov 18, 2020

Travis macOS and appveyor seem to be fixed. But now the same problem as appveyor showed up in github actions. Rebuilding cutter-deps will be required.

This was referenced Nov 18, 2020
Closed
Closed
@karliss
Copy link
Member Author

karliss commented Nov 21, 2020

Building using latest clang didn't help.

@karliss
Copy link
Member Author

karliss commented Nov 21, 2020 •
edited
Loading

Found an issue describing the problem microsoft/STL#1300 . They have a fix in next VS udpate in which case the appveyor workaround temporarily using older image is fine. But the problem remains for github actions. If github actions don't have similar option for using older build image maybe it can be solved by doing the downgrade at project level. From what I remember VS supported installing multiple toolchain versions for the current MS major version and selecting them in project, not sure if github has any of the older versions installed.

@karliss karliss added this to the 1.13.0 milestone Dec 11, 2020
@karliss
Copy link
Member Author

karliss commented Dec 11, 2020

I have rebuilt cutter deps using older VS version.

@karliss karliss mentioned this issue Dec 17, 2020
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CI Continuous integration High Priority This issue should be handled as soon as possible since it describes a major problem in Cutter
Projects
None yet
Milestone
2.0.0
Development

Successfully merging a pull request may close this issue.

Run cutter appimage packaging in GHA. karliss/cutter
Fix windows CI build karliss/cutter
1 participant
@karliss