note - edited title and message- code signing was irrelevant here… I think it was just a Script Debugger update that stopped my prior code from working. I had at first mistakenly thought it related to code-signing.
We keep code in git, and sometimes need to deploy an entire branch of code for testing. I’ve got one script that deploys a script, and then a second script that calls that first script in a repeat loop to deploy all the scripts on a git branch.
This used to work fine, but it appears that some update to Script Debugger broke what it was doing, by showing a dialog when it exports.
We export it with: save activeDoc in POSIX file savePath as exportFormat with run only
Slightly later in that script, it ends, returning a log of any errors it got to the parent script for batching.
However, as soon as the line: save activeDoc in POSIX file savePath as exportFormat with run only
runs, the script being exported displays a sheet dialog:
Exporting run-only version
Export completed.
Press Notarize to pass the exported file to SD Notart for submission to Apple for notarizing, or Reveal to reveal the exported file in Finder.
I have to click “OK” there, which means it won’t actually batch files. But then also, it immediately returns:
AppleEvent timed out. (-1712)
To the script trying to batch the files, which stops it from running the next iteration of the repeat loop.
Do I need to switch this from using the “save” command to “export?” What’s the best way to batch-save code-signed apps?
I’ve got this test script I’ve been using to try to bypass the issue:
tell application "Script Debugger"
set activeDoc to document "[a script name]" of first script window
set docName to the name of activeDoc
set savePath to "/Users/work/Downloads/TestSave.app"
set exportFormat to enhanced application
set developerID to "Developer ID Application: [my developer ID here])"
set codesign identity of activeDoc to developerID
save activeDoc in POSIX file savePath as exportFormat with run only
tell application "System Events"
tell application process "Script Debugger"
tell window docName
if exists sheet 1 then
tell sheet 1
repeat 200 times
set buttonProps to (properties of button "OK")
if enabled of buttonProps is true then
click button "OK"
exit repeat
else
delay 0.1
end if
end repeat
end tell
end if
end tell
end tell
end tell
end tell
And this works perfectly… and I put this same code is inside my Deployment Script, and run directly from Script Debugger, it runs perfectly. Dismisses the dialog. But when I try to run the Deployment Script in a repeat loop from the batch script, it never executes past the “save” line… it just waits at the “save” with the notification sheet still attached to the window.
When I manually click the “OK” button on the sheet, then it returns "AppleEvent timed out. (-1712).
So I guess it behaves differently when called from another script?
The Batch Deployment script:
sets an alias to the deployment script
opens a file to be deployed in Script Debugger
runs the Deployment Script like this: set scriptReturn to (run script pushScriptScript with parameters ("false"))
Closes the open script
Repeats
I’m surprised I am seeing different behavior from the Deployment Script depending on whether it’s run directly or called by Branch Deployment script.
So, at the moment, I’ve got it working by just turning my entire “Deploy Script” script into a handler inside my “Deploy Entire Branch” script, which stops it from returning the “AppleEvent Timed Out” error following a successful save, and lets my UI code to click “OK” work.
But I’d still, ideally, like a better way to export from Script Debugger that doesn’t involve UI scripting clicking an “OK” button when it exports… and then, separately, I’m very curious why the same code behaves differently depending on whether it’s run as a “run script” or run directly in the code of the main script. I might cross-post that second issue to MacScripter, as I don’t think it’s intrinsic to Script Debugger, and I’d like to know what other think who may not hang out here. I’d love to know under what circumstances the same code may behave differently based on how it’s run.
The fact that you have to is a bug, and should be fixed in the next beta. The problem is that the scripting command is returning before the dialog has been closed.
In the emantime, you could probably replace the UI scripting stuff with a delay, if you’d prefer.