Is this project largely abandoned by its original creator(s)? about nucleus HOT 14 OPEN

The actual answer to this issues original question is basically "yes". I built and maintained the nucleus project while I worked at Atlassian. I no longer work there and therefore don't have commit rights on this repository anymore and I don't think anyone there is actively maintaining this project as it current Just Works ™️ for their internal use case.

Your best bet is convincing atlassian to hand off the project and transfer it somewhere like electron-userland so that folks can land PRs again. But yeah, without anyone with commit rights this project is currently stranded (and has been for almost 2 years now)

from nucleus.

It's worth noting that Squirrel is still the official auto-update solution for electron, as per the docs.

Nucleus is stable and is a good solution if the current feature set meets your needs. Unfortunately, it doesn't seem that Atlassian put enough resources towards this project and outside contributions aren't enough to float it. The main alternative for a hosted solution, electron-release-server, is in a similar boat: stable but not being very actively maintained.

I came to the conclusion to avoid using a release server all together, especially considering that we're looking to integrate the builds into Gitlab CI eventually and these release servers are quite manual. What we're doing is similar to b-zurg, just letting S3 (in our case DO spaces) do the heavy lifting, however, we just use the electron-forge s3 target directly as follows:

    ...
    makers: [
        {
            name: '@electron-forge/maker-squirrel',
            config: {
                setupExe: 'Setup.exe',  // Always overwrite setup executable giving fixed path to latest exe
                remoteReleases: 'https://<bucket>.<region>.digitaloceanspaces.com/<folder>'
            },
        }
    ],
    make_targets: {
        win32: ['squirrel'],
    },
    publishers: [
        {
            name: '@electron-forge/publisher-s3',
            config: {
                bucket: '<bucket>',
                endpoint: 'https://<region>.digitaloceanspaces.com',
                folder: '<folder>',
                region: '<region>',
                public: true  // I don't think you can do serverless unless assets are public
            }
        }
    ],
    ...

Then we simply point the auto-updater at the bucket:

autoUpdater.setFeedURL('https://<bucket>.<region>.digitaloceanspaces.com/<folder>')

The reason this works is because Squirrel itself can work with a simply static filesystem or server, all the logic is baked into Update.exe itself. It simply looks at the RELEASES file at the feed url and determines if it needs to update with the listed nuget packages.

The downside is that you have to set up channels/architectures manually with your bucket folder structure, but our app is Windows only for now anyways. You also lose the ability to stage/rollout releases but if you handle this in CI anyways then it doesn't matter.

This setup, while limited, is dead simple and quite foolproof assuming you are okay with the release going out as soon as the publish command completes.

Note: be careful if you use a CDN! If RELEASES gets cached then the app won't update until it gets the new version.

from nucleus.

This is a pretty good overview https://www.github.com/atlassian/nucleus/tree/master/docs/Architecture.md

I also recommend checking the documentation of Squirrel.Windows and Squirrel.Mac as electron really just uses those under the hood.

from nucleus.

@Brouilles I don't know what you mean by "use s3" but you can certainly upload files manually. A yarn build will generate a setup exe for initial installs, a nuget file for updates and a RELEASES files which the auto-updater uses to check for new releases.

These can manually be uploaded to any server, network share or filesystem. Just point the auto updater at the base URL or directory which is hosting those files.

from nucleus.

That's what we had before setting up the auto-updater, but now it does remove previous versions. In any case, it's on the squirrel side as you already figured.

from nucleus.

I have been on a personal journey through all of the different release servers and update options that is offered for electron.. It's a very frustrating landscape of forgotten projects and a lack of security consciousness.

However among the options I do believe this is the best. I was able to set it up with an ecs Fargate cluster in a container that connects to postgres and S3 and can be scaled up my CI job before publish and scales down after, which minimises attack surface to just S3.

So it takes some work but it's possible. Due to a timeout bug (which I have a PR for) I'm running my own docker image for now.

So all this to say it's possible to get this running in the way that you're imagining. As for docs.. yes they can be improved but are better than the others. I think the fundamental ideas behind this server is the most sound out of all the options.

from nucleus.

Thank you for sharing, @b-zurg . I saw the same landscape littered with abandoned Electron update servers, even those still referenced by the Electron web page. I do realize that given enough time and effort this project can be revived. But to me going with self-hosted server product only makes sense if it can be done somewhat easier than going with the managed service like update.electronjs.org. I didn't go with managed service because of the restrictions like having code signed, for which on MacOS I need to be a part of Apple Development Program, and to set up Authenticode signing for Windows, etc. That's quite a few hoops to jump through, and I thought I'd rather build a CDK project deploying AWS infra and self-host this product. Doing so I thought would be easier. As it turns out, I might have been wrong. So while doing this is possible, it does not seem to be practical, especially given the number of critical security vulnerabilities in the base image. Do you think otherwise? If you have fixed security issues too, that's a great accomplishment!

from nucleus.

Yes I agree having any sort of server for updates is a security vulnerability in my opinion. the thing that makes this product viable is that the server only needs to be running for the time that you're publishing or releasing the application. The rest of the time you're just using S3.

The way I have my project setup is I'm using nucleus as a serverless release server. In this way the attack surface of the vulnerabilities of the server itself are mitigated by the fact that it only needs to be running for a few minutes at a time. with fargate on a load balancer you can further increase the security by having IP restrictions if you need and can easily rotate secrets using AWS parameter store.

As long as you lock down your S3 then your update "server" is secure - and securely configuring S3 is far easier and more reliable than any other server-based update mechanism.

from nucleus.

Being very new to Electron, I'd like to make sure I understand you correctly: your Electron app(s) when checking for update, go straight to S3, not involving the server, and the server is used only to upload the updated bits of a new version? If so, if you could point to where I could read about details of this setup, I'd appreciate it.

from nucleus.

Thank you. Quick note: Squirrel.Windows is deprecated.

from nucleus.

@damienallen does electron forge automatically create a RELEASES file and put it in S3? If so then this is a very nice option.

I find this whole release server concept so unnecessary in general so it's very nice that you found a way to use the default updater with just object storage.

In the end I gave up on this route and just use electron builder now as it allows me to only have S3 as my update infrastructure and build easily in CI.

from nucleus.

@MarshallOfSound Nice to have a bit of closure to this question. We've been using nucleus for almost 2 years and it really helped get our electron app into action. This is really a solid tool you built!

@b-zurg Election Forge does indeed automatically upload the assets generated by Squirrel to S3 including an updated RELEASES file.

I was looking into election builder too but didn't want to have to deal with a migration to NSIS. However, the nucleus system diagram was super useful in finding this alternate solution. This was my first electron app so the lines between forge, squirrel, nucleus and the built-in auto-updater were not clear to me until recently.

from nucleus.

@damienallen Do you know if it is possible to use S3 to generate locally files and upload manually later on any server? Like Electron Builder (but not compatible with Electron Forge). Can be awesome.

from nucleus.

Yes sorry. It is not clear. And I have found how to do this. I have just a problem with squirrel who doesn't delete old version after update 🙄. I don't know if it is normal or not. But very annoying.

from nucleus.