-
Notifications
You must be signed in to change notification settings - Fork 325
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
Reproducible Build #306
Comments
Created a test branch: ipfs-inactive/js-ipfs-http-client#626 please test |
@lidel would be be allowed to submit a new version of the add-on that was built with a package-lock.json file? That way the transitive dependencies would all be pinned at specific versions as well as the direct ones. That plus a Dockerfile should be enough to get a reproducible build for future releases. I'll submit a PR with a Dockerfile and a package-lock.json |
Ok so, i'm pretty sure that we're ok on this. From the docs Example_Desired_outcome section of the code submission docs, it sounds like they want to be able to run the same commands we did to create the release, and be able to diff the output with the contents of the uploaded bundle. i've tried running the build in docker (simulating debian jessie), and running it locally on osx, and recursively diff-ing the unzipped build artefacts reveals no differences. 🎉 I think that's all that moz want to see. Looking at the source for a popular firefox addon, emoji-helper it looks like they are doing nothing fancier than adding a packge-lock.json. I think we should do that too, but I don't think we need to do anything urgently to get through the review process, unless moz have specific questions. |
@lidel i've just re-read the title of this issue... did moz already raise an issue about
|
Yes, we need to make new releases (extension + deps: js-ipfs-api and is-ipfs), as we are unable to replicate build of already submitted one.
Indeed, they already requested that (see #306 (comment), added original feedback there) |
Steps are:
So we are kinda waiting for 1) PS. I wonder if it would not be easier to browserify entire thing (#311) instead 🤔 |
Strongly agree! browerify + a It's still worth getting those libs builds to be reproducible, but it'd be nice to get that off the critical path to getting moz happy with
I've not used yarn enough to say. I've not had any problems with npm, but I know that the package-lock merging dev experience needs improving. I saw this nugget from kat the other day
https://twitter.com/maybekatz/status/930523154253877248 which I'm looking forward to trying. |
Perhaps lock merging with |
Status update: 7 day window from Mozilla will end today and we need to solve it either by enabling yarn+docker in deps (ipfs-inactive/js-ipfs-http-client#626) or switching extension's build to browserify (#311). (Worst case scenario is an emergency release with browserify that does not have working tests.) |
Removes private fields from bundled package.json, part of #306 effort
Adds `npm run docker-build` command, part of #306 effort
Alright, we now have two ways of making a reproducible build of With Nave+Yarn
With Docker+Yarn:
I feel quite comfortable with this setup (big thanks to @olizilla for pushing this!). Let's keep this issue open until first "reproducible release" is reviewed and accepted at Mozilla. |
I've just submitted v2.1.0, fingers crossed 🤞 |
I think it is done for now, yarn-based release build seems to not raise any red flags |
Post-submission review process at Mozilla kicked in for ipfs-companion and requires us to provide source code + build steps that will produce exactly the same code as one published to NPM:
Problem 1
I am unable to replicate build results for two of four dependencies:
ipfs-api
andis-ipfs
.I downloaded https://github.com/ipfs/js-ipfs-api/releases/tag/v15.0.1 but was unable to produce the same file as https://unpkg.com/ipfs-api@15.0.1/dist/index.min.js -- after running
npm install && npm run build
minified code looks different. Same goes foris-ipfs
.This may be due to different version of
node
,npm
or lack ofpackage-lock.json
/yarn.lock
.Mozilla Reviewer is okay with using specific versions, as long as we provide step-by-step build instruction that result in correct file, matching the one from NPM.
Problem 2
We have 7 days to provide "sources and build steps", otherwise ipfs-companion will be removed.
@diasdavid @dignifiedquire @fbaiodias – any ideas on how to address this?
The text was updated successfully, but these errors were encountered: