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.

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

Mac: Try re-enabling CodeQL on non-legacy build again #2926

Open
hoffie opened this issue Oct 19, 2022 · 7 comments
Open

Mac: Try re-enabling CodeQL on non-legacy build again #2926

hoffie opened this issue Oct 19, 2022 · 7 comments
Assignees
Labels
feature request Feature request tooling Changes to the automated build system

Comments

@hoffie
Copy link
Member

hoffie commented Oct 19, 2022

What is the current behaviour and why should it be changed?
In #2564 we've moved the CodeQL logic to the legacy build target. The reason was that enabling CodeQL got the build stuck during release signing. The legacy build is not signed, therefore, the problem didn't appear there.
I'm suspecting that it might be the same cause as #2925. In other words: It might just be that CodeQL builds are slower (they are!) and therefore hit the keychain re-lock timeout, which can be worked around.

Describe possible approaches
When #2925 is fixed, we could just re-enable CodeQL for the main build (and disable for legacy).

Has this feature been discussed and generally agreed?
No, but if it works, it should be good to go as it was a workaround only.

@hoffie hoffie added the feature request Feature request label Oct 19, 2022
@hoffie hoffie added this to the Release 3.10.0 milestone Oct 19, 2022
@hoffie hoffie self-assigned this Oct 19, 2022
@hoffie
Copy link
Member Author

hoffie commented Oct 30, 2022

Well, no, it doesn't seem like #2925 is sufficient to avoid this issue, see https://github.com/emlynmac/jamulus/actions/runs/3357222609/jobs/5562884622#step:10:1838

@ann0see
Copy link
Member

ann0see commented Nov 6, 2022

Maybe it's still something related. I remember @danryu changing some timeout to 6h.

@danryu
Copy link
Contributor

danryu commented Nov 6, 2022

Maybe it's still something related. I remember @danryu changing some timeout to 6h.

I think you're probably referring to the keychain settings timeout in this PR: #2624
Which is still not merged ;)
That timeout was taken from example Github docs on XCode: https://docs.github.com/en/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development
It simply keeps the keychain unlocked for the specified period (up to 6 hours). This is done to ease the various CI jobs that require keychain access in the same build run.

Btw I just added signed package validation and upload to the App Store to that PR - the code is working for us.

@hoffie
Copy link
Member Author

hoffie commented Nov 7, 2022

I've just commented in #2624: I think that 6h timeout is redundant now that #2927 has been merged (it drops exactly that timeout, AFAIU). That was the initial reason for this PR. :)

The best way forward would probably to try to get GUI access. Github shows some hacks to do that, but I haven't got around to try them.

@pljones
Copy link
Collaborator

pljones commented Apr 19, 2023

See #3049 - same thing for Linux now?

@pljones pljones added the tooling Changes to the automated build system label May 21, 2023
@pljones
Copy link
Collaborator

pljones commented Jun 25, 2023

Dropping from 3.10.0.

@pljones pljones removed this from the Release 3.10.0 milestone Jun 25, 2023
@pljones pljones added this to Tracking Jun 25, 2023
@github-project-automation github-project-automation bot moved this to Triage in Tracking Jun 25, 2023
@softins
Copy link
Member

softins commented Feb 10, 2024

Now that the sudo workaround has been merged in #3223, I have done a build with CodeQL on the main MacOS instead of on the legacy MacOS, and it worked fine.

I could raise a PR to make the change if generally agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Feature request tooling Changes to the automated build system
Projects
Status: Triage
Development

No branches or pull requests

5 participants