Build and publish safari browser extension - #681
Siedlerchr wants to merge 74 commits into
Conversation
TODO: Setup browser extension project in Apple developer
tobiasdiez
left a comment
There was a problem hiding this comment.
Thanks a lot!
Looks like this PR contains a few unrelated/unnecessary or otherwise strange changes (AI generated??). Can you please revise this, or at least explain the need for the changes.
The main issue is the whole scripts/makefile setup. In the wxt world, you solve this by "modules" that hook into the build progress and modify/postprocess the output. You might be able to reuse https://github.com/rxliuli/wxt-module-safari-xcode or at least get inspiration how its done.
Can you do this please, and then configure the securities in the gh actions to actually be able to test the publish/notarize workflow. |
Add workflow for maual safari tests
* origin/main: Add workflow for maual tests
set unique safari build number
* origin/main: set unique safari build number
|
Uploading to apple app store connect works now. |
# Conflicts: # .github/workflows/test.yml # README.md # pnpm-lock.yaml
* origin/main: fix: limit Chrome-only permissions to non-Firefox browsers (#696) # Conflicts: # wxt.config.ts
|
@tobiasdiez I streamlined the code, refactored it, reviewed and tested the changes again, and verified the keys against manifest v3 once more. All these changes to the keys here are done deliberately to follow v3. This PR now also enables distribution and notarization of the app outside the app store without having to wait for Apple review. On Mac, installing a browser extension is basically a separate app you install.
Would be great to have this in and then a new release across all browser |
|
Can you please paste the links to for the test runs for the CI workflows? Thanks! |
|
@tobiasdiez Packaging.: https://github.com/JabRef/JabRef-Browser-Extension/actions/runs/33417738312/job/99572341682?pr=681 Building the extension and the app Manual notarizing workflow which upload it to app store connect |
# Conflicts: # wxt.config.ts
|
Thanks, but I still don't get how these jobs are supposed to work / what purpose they have. It looks like:
Why can't we just have a simple matrix in the release workflow (with browser = [firefox, safari]) that runs |
|
I tried to unify it a bit more: Safari App Store: Xcode build -> Xcode archive/sign/package with certs for App Store → App Store Connect -> (notarization or whatever security checks happen in appstore) Different distribution requires different certs and entitlements (sandboxing etc) safari-signing-test.yml (just a simple manual/smoke test for uploading testing ) |
|
Do I talk again to Claude?
Why do we need this? So far we don't publish any build artifacts in the GH release, and nobody asked for it. Also why not simply use the |
|
As I wrote earlier, these are two different things. And no, we cannot reuse the build mode of the safari-wxt-extension because it's explicit only for the app store (different entitlements, signing stuff, certs, etc.) . Direct distribution is for downloading the app-file outside the app store (JabRef itself is also not available in the app store). It's explicit for users who don't want to use the Apple App Store or cannot use the App Store due to restrictions. Only because the other extensions are not published doesn't mean we cannot publish it as a release artifact. Does no harm, but rather improves the user experience for users who want to try out the extension with safari |
* origin/main: chore(deps): update dependency oxlint to v1.80.0 (#730) chore(deps): update dependency oxfmt to v0.65.0 (#729) chore(deps): update dependency node to v24.20.0 (#728) chore(deps): update dependency globals to v17.11.0 (#727) chore(deps): lock file maintenance (#722) chore(deps): update dependency wxt to v0.21.4 (#726) chore(deps): update dependency vue-tsc to v3.3.11 (#725) chore(deps): update dependency vue to v3.5.42 (#724) chore(deps): update dependency vitest to v4.1.11 (#723) # Conflicts: # .github/workflows/release.yml # .github/workflows/test.yml # package.json # pnpm-lock.yaml
* origin/main: chore(deps): update pnpm/action-setup action to v6.1.0 (#734) chore(deps): update dependency oxlint to v1.81.0 (#733) chore(deps): update dependency oxfmt to v0.66.0 (#732) chore(deps): update dependency globals to v17.12.0 (#731) chore(deps): update pnpm to v11 (#676) Co-authored-by: Junie <junie@jetbrains.com> # Conflicts: # .github/workflows/release.yml # .github/workflows/test.yml # pnpm-lock.yaml
Ideally, browser extensions would be included or offered during JabRef installation for a smooth user experience. JabRef is distributed outside the app store so it seems reasonable to offer the extension the same way (like 1Password, for example, I believe). Distribution outside the app store would allow installation without an Apple ID, which is how I use macOS. I don't suppose this is a common use case. |
# Conflicts: # .github/workflows/release.yml


Uh oh!
There was an error while loading. Please reload this page.