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

"quiet" package option can not be override #3540

Closed
3 tasks done
jdeniau opened this issue Mar 18, 2024 · 2 comments · Fixed by #3831
Closed
3 tasks done

"quiet" package option can not be override #3540

jdeniau opened this issue Mar 18, 2024 · 2 comments · Fixed by #3831
Labels
package Issues related to the `package` command

Comments

@jdeniau
Copy link

jdeniau commented Mar 18, 2024

Pre-flight checklist

  • I have read the contribution documentation for this project.
  • I agree to follow the code of conduct that this project uses.
  • I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version

7.2.0

Electron version

28.2.3

Operating system

macOS 14.3.1

Last known working Electron Forge version

No response

Expected behavior

I'd like the packagerConfig.quiet to be default to true, or at least to let me change it's value.

Actually it's "locked" by the following lines :

quiet: true,
dir: ctx.dir,
arch: arch as PackagerArch,
platform,
afterFinalizePackageTargets: sequentialFinalizePackageTargetsHooks(afterFinalizePackageTargetsHooks),
afterComplete: sequentialHooks(afterCompleteHooks),
afterCopy: sequentialHooks(afterCopyHooks),
afterExtract: sequentialHooks(afterExtractHooks),
afterPrune: sequentialHooks(afterPruneHooks),
out: calculatedOutDir,
electronVersion: await getElectronVersion(ctx.dir, packageJSON),
};
packageOpts.quiet = true;

(both lines 305 and 317 do force the value to false after the custom user configuration).

Actual behavior

When trying to sign the app, I got issues that I could not debug without having to go deep into the code and console.log things

I used both DEBUG=electron-osx-sign* and DEBUG=electron-notarize*, but I still struggled at some point (see below).

Steps to reproduce

I do not know if you can reproduce this, but I can show the deep dive I had to do (quick version).

For the record, with the same configuration, I had no issue on a mac "x64".

When trying to sign and notarize a mac app, when running yarn make, I got the following output

[STARTED] Packaging for arm64 on darwin
[STARTED] Copying files
[SUCCESS] Copying files
[STARTED] Preparing native dependencies
[TITLE] Preparing native dependencies
[SUCCESS] Preparing native dependencies
[STARTED] Finalizing package
2024-03-17T20:11:59.644Z electron-osx-sign [email protected]
2024-03-17T20:11:59.645Z electron-osx-sign `identity` passed in arguments.
2024-03-17T20:11:59.645Z electron-osx-sign Executing... security find-identity -v
[FAILED] Failed to codesign your application with code: 1
[FAILED] 
[FAILED] Tiana Tables.app: code has no resources but signature indicates they must be present
[FAILED] 
[FAILED] 

By running with DEBUG=electron-osx-sign*, the last log I got was Walking... from https://github.com/electron/osx-sign/blob/97b1e13b9a6de43a5add8dccf609ac10a780b1e8/src/util.ts#L136

I tried adding a line just bellow and nothing was displayed.

I added a try / catch, and then I got an issue displayed with EMFILE: too many open files (but that's not the point of this issue).

By going up with this, I found that all error send in the signApp, will be throwned to the caller (as mentioned in the documentation).

I then went into the packager package, that does call signApp here where there is a continueOnError option

https://github.com/electron/packager/blob/d5cd2b7dcd8e85c1c1bdcdd3c4e77edc9ac729f2/src/mac.ts#L404-L414

I tried to add this option into my osxSign option, but TypeScript does throw with

Object literal may only specify known properties, and 'continueOnError' does not exist in type 'OsxSignOptions'.ts(2353)

I continue to dive as I did not saw neither the error, nor the warning message "Code sign failed; please retry manually"

In the warning function, we do nothing when the quiet option is true : https://github.com/electron/packager/blob/d5cd2b7dcd8e85c1c1bdcdd3c4e77edc9ac729f2/src/common.ts#L30

I tried to set the quiet option in my packagerConfig object. TypeScript is OK with this, still no log.

image

As I said in the "Expected behavior" section, it's locked here

quiet: true,
dir: ctx.dir,
arch: arch as PackagerArch,
platform,
afterFinalizePackageTargets: sequentialFinalizePackageTargetsHooks(afterFinalizePackageTargetsHooks),
afterComplete: sequentialHooks(afterCompleteHooks),
afterCopy: sequentialHooks(afterCopyHooks),
afterExtract: sequentialHooks(afterExtractHooks),
afterPrune: sequentialHooks(afterPruneHooks),
out: calculatedOutDir,
electronVersion: await getElectronVersion(ctx.dir, packageJSON),
};
packageOpts.quiet = true;

Additional information

I would like your input about if this is intended, if I could open a PR that either allow "quiet" to be changed, or if "true" should be the default value (or both).

For the record, the quiet option has been added in #8 by @malept 8 years ago.

@erickzhao erickzhao added bug package Issues related to the `package` command labels Apr 18, 2024
@KenCorma
Copy link

I also agree that this should have been an optional parameter that could have been set by the config. I dealt with a lot of issues that I had no starting point for, only seeing this issue let me create a shim to override it. This would have saved me a lot of time. I also don't understand the decision to have Continue on error forced on Osx sign then to continue onto OSx-notarize. You will NEVER be able to notarize a package with a failed codesign output, and in my opinion it should just throw an error there.

@erickzhao
Copy link
Member

I'm not opposed to making this behaviour configurable and just defaulting to quiet by default :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package Issues related to the `package` command
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants