Everyday users want to use a native OS installer to install apps. In order to support this, we need to use a package builder like electron-builder to generate those installers.
What to do:
There's some helpful, but slightly outdated, info in #20.
Related Issues: closes #16, closes #20
This is now possible thanks to the work @thisconnect did on js-ipfsd-ctl. @hacdias does this sound like something you can tackle as well? You can find docs on packaging left by @thisconnect here: https://github.com/ipfs/js-ipfsd-ctl#packaging
So, this is related to #512. Dear CI master @VictorBjelkholm, the command to build the distributables is:
./node_modules/.bin/electron-forge package --arch=ia32,x64 --platform=win32,linux,darwin
You just need to change the arch and platform flags to build for the desired platforms and arches. The output will be saved on:
./out/{package_type}/{arch}/files_are_here
If it simplifies your life, there is the publish command you can use: https://electronforge.io/cli/publish.
Hope it helps!
@hacdias started working on this here: https://github.com/ipfs-shipyard/station/pull/514 still a work in progress.
Let's just leave this opened until Packaging is fully working.
Sooooo! Since @diasdavid merged #514, Jenkins is actually building the right stuff! And the binary for Windows is running flawlessly and I'm very happy with it!!! Thanks @VictorBjelkholm!!!
Although, there is this "problem" on Windows:

We have to sign it somehow as it is stated here so the publisher is recognized and this message doesn't prompt out.
On Ubuntu/Mint this problem persists.
@hacdias woah! That's great news! Hm, signing will be a bit trickier to solve right now, as we don't have secrets-management in jenkins yet but it's planned already because we have other builds that will need it as well.
I think this same problem happens in macOS (you'll need to right-click and then click open instead of double-click, otherwise you get a similar dialog) so maybe not a blocker for now.
@VictorBjelkholm okay then. Soooo, the only problem are the Linux builds! Those don't add an icon nor anything to the path. I'll try to figure out why.
@VictorBjelkholm @hacdias can we start adding the working builds (Windows and Mac OS X) to https://dist.ipfs.io/ ?
Manually verified ones, I don't see a problem with that.
However, automatic releases (from jenkins point of view) is missing trusted workers and dealing with secrets from within build jobs. Also, from Stations point of view, we would need to have some sort of testing before automatically release things.
Only Windows and macOS builds are working correctly right now, right?
As per @VictorBjelkholm :
09:13 <@daviddias> victorbjelkholm: let's ship those ipfs-station builds!
09:14 <@victorbjelkholm> daviddias: ship as in? Already being built for the three platforms
09:15 <@daviddias> is that so?? https://github.com/ipfs-shipyard/station/issues/508 doesn't tell me that
09:15 <@daviddias> awesome though!
We are ready to make a release! @hacdias would you like to do the honors and fill https://github.com/ipfs-shipyard/station/releases/tag/untagged-50a0768f417fccfc1ed1?
Rough task list:
Do we need Apple and Windows developer accounts to get the releases signed?
@diasdavid about Windows, check this link: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
@lgierth would love your thoughts here (Release Signing)
I'm wondering if we can have a Alpha Release Key that specifically says that all the software is very Alpha and so it should not be trusted independently of the signature checking out.
@VictorBjelkholm you can set the script to remove the .nupkg files since they aren't needed.
Linux builds are only working with sudo. Permissions are wrong. Can it be a build related thing?
I really want to check this today and let this finished today. I'm not sure if I will be able to do so, but I'll try. Will update this this afternoon.
@diasdavid can you check if the latest macOS build works?
Had to give perms for it to run on the Security pane of System Preferences, but yeah, it works!

Nice! The only problem then is on debian.
So, I solved the problem on debian but i need your help @VictorBjelkholm:
See this:
Can you set postinst.sh permissions to be 755 before starting the build? π
Huh, that error is new. Before the builds were successful but the resulting
.deb was broken, now the build is broken.
I'll try to change the permissions and see what we get.
On Thu, Dec 14, 2017 at 4:35 PM, Henrique Dias notifications@github.com
wrote:
So, I solved the problem on debian but i need your help @VictorBjelkholm
https://github.com/victorbjelkholm:See this:
https://ci.ipfs.team/blue/organizations/jenkins/IPFS%
20Shipyard%2Fstation/detail/master/5/pipeline/15#step-51-log-23Can you set postinst.sh permissions to be 755 before starting the build?
πβ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ipfs-shipyard/station/issues/508#issuecomment-351745455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcD9I1jkLByX5Wi6sJk3sZ8nVp8M3M5ks5tAUAngaJpZM4NT8yM
.
Don't worry, you just need to change the perms of that file. That file is the fix for the debian package π¦
@lgierth would love your thoughts here (Release Signing)
Puh good question -- prior discussions: ipfs/distributions#51
We have a demand for signing web extensions too.
@VictorBjelkholm hello! How's the state of this?
@VictorBjelkholm ping.
solved in c2e703c17b6b99fb18db06c7202ea82a7058a23e
@diasdavid @VictorBjelkholm I think the version from master is ready to be shipped and I'm not aware of any bugs it might have. What do you think?
@hacdias if everything has been tested with those specific binaries, then I say go for it! π My only reservation is towards automatic builds + publish without having any automatic tests.
@VictorBjelkholm we can skip automatic builds for now until we have tests π
@diasdavid let's do this?
What's the real blocker with automatic builds?
So, we don't have testes yet, but I do think the current version (on master) is stable enough to be released into dist.ipfs.io. I tested it on Linux (Mint) and Windows and both versions worked fine. @diasdavid tried on macOS.
Despite not having the automatic builds, we can build the packages for each platform and release the first version (@VictorBjelkholm, what happened to Jenkins? It's not building the new versions).
Donβt know if this is stale (yet), but just saw this great recipe on the quasar discord server:
Gitlab CI awesomeness with docker magick
deploy-windows-64:
stage: deploy
image: electronuserland/builder:wine
environment: production-windows-64
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- npm run pack:win64
artifacts:
paths:
- dist/*.exe
- dist/*.zip
only:
- master
deploy-windows-32:
stage: deploy
image: electronuserland/builder:wine
environment: production-windows-32
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- npm run pack:win32
artifacts:
paths:
- dist/*.exe
- dist/*.zip
only:
- master
deploy-linux-64:
stage: deploy
image: electronuserland/builder
environment: production-linux-64
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- npm run pack:linux64
artifacts:
paths:
- dist/*.AppImage
only:
- master
deploy-linux-32:
stage: deploy
image: electronuserland/builder
environment: production-linux-32
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- npm run pack:linux32
artifacts:
paths:
- dist/*.AppImage
only:
- master
deploy-spa:
stage: deploy
image: node:alpine
environment: production-spa
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- quasar build
artifacts:
paths:
- dist/spa-mat/*
only:
- master
deploy-pwa:
stage: deploy
image: node:alpine
environment: production-pwa
script:
- npm install --silent --global quasar-cli
- npm install --silent
- npm prune
- quasar build --mode pwa
artifacts:
paths:
- dist/pwa-mat/*
only:
- master
this is an excerpt of a package.json where we can use electron-builder to package a Quasar Electron app in a distributable format:
"scripts": {
// (...)
"prepack:linux64": "quasar build --mode electron --target linux --arch x64",
"prepack:linux32": "quasar build --mode electron --target linux --arch ia32",
"prepack:win64": "quasar build --mode electron --target win32 --arch x64",
"prepack:win32": "quasar build --mode electron --target win32 --arch ia32",
"pack:linux64": "electron-builder --linux --x64 --prepackaged ./dist/electron-mat/my-app-linux-x64/",
"pack:linux32": "electron-builder --linux --ia32 --prepackaged ./dist/electron-mat/my-app-linux-ia32/",
"pack:win64": "electron-builder --win --x64 --prepackaged ./dist/electron-mat/my-app-win32-x64/",
"pack:win32": "electron-builder --win --ia32 --prepackaged ./dist/electron-mat/my-app-win32-ia32/"
}
We do this already! π
Most helpful comment
So, this is related to #512. Dear CI master @VictorBjelkholm, the command to build the distributables is:
You just need to change the
archandplatformflags to build for the desired platforms and arches. The output will be saved on:If it simplifies your life, there is the
publishcommand you can use: https://electronforge.io/cli/publish.Hope it helps!