search

quicksilver / Quicksilver

Quicksilver Project Source
http://qsapp.com
Apache License 2.0
2.72k stars 283 forks source link

Make it possible to run `qssign` outside of CI #2868

Closed pjrobertson closed 2 years ago

pjrobertson commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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!