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

Make it possible to run qssign outside of CI #2868

Closed
pjrobertson opened this issue May 9, 2022 · 4 comments · Fixed by #2871
Closed

Make it possible to run qssign outside of CI #2868

pjrobertson opened this issue May 9, 2022 · 4 comments · Fixed by #2871
Assignees

Comments

@pjrobertson
Copy link
Member

It would be great if we were able to sign our own builds locally using qssign. A use case is that I want to build a debug version of the app, or I want to run a signed version of the debug app for testing.

Right now, it seems possible, with a few mods to the qssign script. Here's what I had to do:

xcodebuild -showBuildSettings -configuration Debug -scheme "Quicksilver Distribution"  >> /tmp/qs_build_settings 
cp Quicksilver.entitlements /tmp/
mkdir dmg
cp Resources/Images/QuicksilverDMG.icns /tmp/QS/build/Debug/dmg/.VolumeIcon.icns
cd /tmp/QS/build/Debug
mv ./* dmg

I think that was it. It would be great if the qssign script could detect where it's being run, and do this itself though!

@n8henrie - I'm hoping this is an issue you can handle :D

@n8henrie
Copy link
Member

n8henrie commented May 9, 2022

Makes sense.

We'll continue to get some error message upon opening because the DMG won't be signed -- we don't have local credentials for that (which is a different kind of signature than that used for the app itself).

Currently a Debug build can be transferred to another computer and run without any signing at all, but at least on MacOS 12.3 the detection that it is a downloaded file leads to a "this app is broken" error with no obvious GUI workaround. CLI-savvy users can xattr -c Quicksilver.app and it will run, but obviously that's asking a bit much if you're providing a debug version for another user to test.

I think the easiest / best approach is to add a flag for configuration to qsrelease, which automatically runs qssign. I've tested #2869 and it seems to fit the bill. Current behavior is unchanged and produces a signed release build.

When I run as:

$ SIGNING_IDENTITY='ABCD' Tools/qsrelease Debug

It correctly produces a Debug build, including a DMG that I've transferred to my wife's computer and run. There is the expected dialog requiring one to cmd-click and open (which has been documented before, due to unsigned DMG) but no "broken application" error as one gets with a completely unsigned build. It runs and shows it is indeed a debug build as expected.

@pjrobertson
Copy link
Member Author

Much simpler, I didn't realise I could just run qsrelease locally - no need to run qssign. The only other reason I had for running qssign was if I wanted to sign plugins locally. Do you think that's worth it?

I'm wondering now if we should build a release and debug build on every commit, or just a release build?

@n8henrie
Copy link
Member

n8henrie commented May 9, 2022

I'm wondering now if we should build a release and debug build on every commit, or just a release build?

I wouldn't anticipate much benefit in adding debug builds to CI; we're likely all already running debug builds locally while we develop.

Except... if we take a "random" example: https://github.com/quicksilver/Quicksilver/actions/runs/2291220282

If I changed the Quicksilver.zip artifact to be a Quicksilver-debug.zip, and left the Quicksilver_2.1.0.dmg as a release build, it might be nice to direct users to a pre-build debug build.

Yeah that might be worth doing. And it makes it so having the .zip and .dmg isn't just duplicated artifacts.

@n8henrie
Copy link
Member

Kind of interesting, the output in CI:

$ echo $(arch)
i386
echo $(uname -m)
$ x86_64

So it looks like uname -m may be the way to go regardless!

n8henrie added a commit that referenced this issue May 10, 2022
Also use `uname -m` instead of `arch` to determine host architecture.

Fixes #2868
@n8henrie n8henrie linked a pull request May 10, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants