Electron-builder: Electron Build Service

[develar]

Proud to announce that free public electron build service is launched.

• only linux targets for now.
• native decencies are not handled, please use prebuild.
• NodeJS 8.9.1+ is required.
• at least electron-builder 19.48.2 is required.
• Server is open source — https://github.com/electron-userland/electron-build-service

Depending on your feedback, macOS and Window build agents will be launched.

How does it work: by default. i.e. now you are able to do build --linux on Windows.

Add your reactions to comments below to vote.

[develar]

I want macOS build agent.

[develar]

I want Windows build agent.

[develar]

If you vote for Windows, please explain, because currently only appx target requires Windows.

[Slapbox]

I finally got around to trying the build server and I'm a little confused. After Electron-Builder produces the linux-unpacked folder it then says in my terminal:

Schedule remote deb build for arch x64
Schedule remote appImage build for arch x64
Done in 96.16s

But nothing appears to happen after that even after 10 minutes. What exactly is supposed to happen and what's a reasonable amount of time to expect to wait at this early stage to know if it did work? I know the docs say, _"Queue waiting is not predictable for now,"_ but I'm a little confused about exactly what to expect when the build is completed.

Can you give me any insight? Thanks again @develar and to the entire development team!

[develar]

Right now you can expect AppImage and deb in 80-90 seconds.
Do you see artifacts in your out dir? Is build was finished? What is the name of your app (to check server logs).

[Slapbox]

Thanks very much @develar.

I've retried the process just now, this time with only AppImage as a target and with the application name SlapboxApp.

I do see what appears to be a fully populated folder called linux-unpacked upon completion of my build command, and my command ends off with:

Packaging for linux x64 using electron 1.7.9 to release\linux-unpacked
Schedule remote appImage build for arch x64
Done in 98.74s.

I tried disabling my firewall completely for a few minutes just to be sure as well. Any thoughts? Thanks again!

[develar]

@Slapbox What files do you have in the dist (parent dir of linux-unpacked).

[Slapbox]

Oh I don't have anything there. I'm using electron-react-boilerplate and it seems to put the files into app\dist\ as opposed to release\dist\

I take it this is probably the root of my issue? What I'm doing is running yarn run package-linux from the scripts in the package.json for electron-react-boilerplate.

Any thoughts on how I would proceed in fixing this setup to be compatible? Thanks again!

[develar]

@Slapbox Thanks. Because of Christmas/New Year, I still doesn't have time to investigate. Will be fixed soon anyway.

[develar]

@Slapbox Should be fixed in 19.52.1.

[Slapbox]

@develar I just saw this reply and gave it a shot. Works like a charm! Thanks very much to you and everyone else on the team!

[Georift]

Hey, thanks for providing this service, it definitely makes it more straightforward getting out Linux builds. 😃

However I wonder if we could have a discussion regarding this being enabled by default. I work in an enterprise environment where sending anything to a public service would be considered a big no no. I have since found the remoteBuild option and I'll be using that for all my work projects from now on.

I understand why it's enabled by default, we want to provide the most seamless experience for the user, but perhaps we could change it to an opt-in? Say on windows when we encounter a linux build but no remoteBuildoption present it displays a message saying something like _"Your platform does not support local linux builds. A free public electron build service exists, to enable it set 'remoteBuild' to true"_?

What do you think @develar?

[develar]

@Georift Have your read Privacy? Your project sources stay on local machine, "Only what your end users see and get, are sent to remote build server.".

[FelikZ]

I would love to have all platforms especially Windows, to trigger CI builds remotely, regardless of the platform where the trigger happens.

[Georift]

@develar I'm sorry for taking so long to reply. Yep I've seen the privacy notes, however I think it's worth pointing out that not all builds are destined for the wider public. There may be cases where the application is an internal tool, or a tool used in the day to day operations of a company. The contents of the build even after compiled can still contain sensitive information.

I feel the safest path is to provide at least some information to the user that this is happening. I'd be happy to provide a PR that adds and interactive opt in to keep the user experience as high as possible. What are your thoughts?

[develar]

@Georift PR will be accepted. You can do it or on NodeJS side, or on Go side https://github.com/develar/app-builder/blob/master/pkg/remoteBuild/RemoteBuilder.go We are in transition to get rid of NodeJS in favour of Go, so, better if it will be done on Go side (but please note, that you will need to open input stream on nodejs side, currently stdio configured to ignore, if I am not wrong).

[Slapbox]

@develar, not directly related, but is there anything I can read on why the team decided on Go as opposed to Node? Seems like it would be valuable learning material.

[develar]

why the team decided on Go as opposed to Node

Pyhton/Node/Ruby are not a good languages for CLI tools. Go produces single executable, that you can run everywhere and build everywhere (and end user can install any version of your tool using one simple command). You can use whatever dependencies your want, and so on. Easy to install any version, you can organize your project as you want — it is linker responsibility to build required parts, not you should create myriads small unmaintable hell of node modules. Not to mention go routines (yes, Promise is not a solution).