Skip to content

Conversation

@jschwe
Copy link
Member

@jschwe jschwe commented Dec 4, 2025

Depends on #676 and #677

See the official crates.io trusted publishing documentation.

This requires a crates.io owner of mozjs to allow trusted-publishing!

Configure your crate on crates.io:
Go to your crate's Settings → Trusted Publishing
Click the "Add" button and select your platform (GitHub or GitLab)
Fill in the platform-specific fields and save the configuration

Todo:

  • handle releasing only mozjs, if mozjs changed, but mozjs-sys didn't

@jschwe
Copy link
Member Author

jschwe commented Dec 5, 2025

I can see how it could be useful (to not forget bump if one wants to use this in servo), but also not if we want to land multiple PRs (in short span of time) and not release version for each one (I am worried we will spam to many version - and our crates are big).

Let's continue the discussion from #677 here. If we switch to consistently using crates.io releases, then technically we don't need to build and release a prebuilt version of mozjs-sys for every commit on main, but just for every published release.
So we could tag and release on-demand if wanted. Practically, we probably still want to release often, due to the tight coupling of servo and mozjs(-sys).
Maybe we could parse the commit message and skip publishing if we match some regex that lets us skip the release? That would allow us to default to releasing, and skipping if we know we will be merging multiple related PRs quickly after each other.

I've been wondering about the versioning too - perhaps we should just use a workspace version (following the spidermonkey version, as we already do for mozjs-sys), and not version mozjs independently? That would make version bumps simpler, and we could always just release both libraries. It would be a bit wasteful (in terms of crates.io space usage) if mozjs-sys didn't actually change though.

Signed-off-by: Jonathan Schwender <[email protected]>
@jschwe jschwe force-pushed the trusted_publishingv2 branch from d5c11af to c52dc84 Compare December 8, 2025 07:24
@jschwe jschwe marked this pull request as ready for review December 8, 2025 17:39
@jschwe jschwe requested a review from sagudev December 9, 2025 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant