Ferdi: Enable nightly releases

[kytwb]

Is your feature request related to a problem? Please describe.
Related to https://github.com/getferdi/ferdi/pull/610#issuecomment-616703587. Right now we can't distribute binaries for testing purpose.

Describe the solution you'd like
A way for testers to get binaries before we publish releases.

[kytwb]

@all-contributors please add mahadevans87 for ideas

[allcontributors[bot]]

@kytwb

I've put up a pull request to add @mahadevans87! :tada:

[vantezzen]

We would need to see how we can distribute them then. If we create a pre-release on GitHub with them, everyone with beta versions enable will also update to them, so we may need a separate repo where we can publish them via direct download only?

[kytwb]

@vantezzen I was thinking of leveraging CI artifacts for that; I know we can store artifacts in AppVeyor, not sure about Travis; we can then trigger a build on a internal-release branch and reference to the artifacts of the internal-release build for testers to download and test?

[vantezzen]

Otherwise we can also think about setting up a "nightly" channel like ElectronJS uses them.
I just looked at the docs of electron updater and it looks like the feed url can be changed (https://www.electron.build/auto-update#module_electron-updater.AppUpdater+setFeedURL).
My idea would be:

• Set up a new GitHub repo getferdi/ferdi-nightly. This repo would only be used for releases and wouldn't contain any actual code
• We can start TravisCI and AppVeyor every few days to create a new nightly build that will be published to that repo
• In addition to the "beta" toggle, users can also toggle "nightly" which will change their electorn-updater feed to getferdi/ferdi-nightly

We'd have to see if that setup really works like I imagined it to. WDYT?

[kytwb]

@vantezzen I think it would work too! Now we have to make a choice about the implications of each implementations and the resources at hand. Do we really want to expose nightly builds so easily to non-developers too?

[vantezzen]

We can add a separate warning screen or maybe only allow activating it though a more "hidden" setting (e.g. by writing something in the quick switch) but I think it shouldn't be made too difficult to switch to nightly builds.

[vantezzen]

Working on this at https://github.com/getferdi/ferdi/tree/feat/nightly-releases. We'll now have to see how we can create a configuration that allows us to release those nightly builds to https://github.com/getferdi/ferdi-nightly.
We'll also have to see if the feed switching works the way I currently implemented it - I couldn't find a lot of documentation about how it's done.

[vantezzen]

This should now work on Ferdi's side, but we'll need to look into how we can configure our build system to support nightly releases, too.
@kytwb Do you have any idea how we can achieve this? I think the optimal case would be that whenever we create a release in the ferdi-nightly repo, Travis and AppVeyor automatically build it (like we have it setup for normal Ferdi), but that repo would not contain the required environment variables, right?

[kytwb]

@vantezzen I guess we can add ferdi as a git submodule of ferdi-nightly, and trigger a nightly build everytime we update the ferdi submodule ref? We can proceed the same way as for Ferdi, but we would have to change the current working directory to be in the ferdi submodule when building. We would need to set the environment variables for ferdi-nightly builds as well.

[kytwb]

Almost there, did without the submodule and without having to maintain the secrets in a new repository environment variables; re-using ferdi existing pipeline with the nightly branch. I need to fine-tune a couple of things (getting inspiration from https://github.com/electron/nightlies/releases).

Current status:

Via https://travis-ci.org/github/getferdi/ferdi/builds/682209745

[kytwb]

Thanks to npm version prerelease --preid=nightly:

We now need to commit and push the package.json and package-lock.json files (which contains the updated version attribute) so the next nightly build will be 5.5.1-nightly.1. I am note sure what is the best way to do this given we have 2 CI (AppVeyor/Travis) and 2 matrix in Travis (macOS/Linux). We can probably determinate a "lead" CI that will be in charge of doing the commit/push on success on the nightly branch, likely Travis. The drawback with this approach is that we silently allow AppVeyor to fail and could end up with nightly releases without the Windows artifacts (should not happen often but worth mentioning to be aware of it

For Travis, we would want to push/commit after these two jobs are successful:

[kytwb]

Published v5.5.1-nightly.8 for now as it contains all the assets (even though the Travis build failed, as both build jobs try to push back the npm version update back to git (only 1 succeed as expected). That's why I wanted to run the git push in another build stage but I haven't successfully done so yet.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please check if this issue is still relevant and please close it if it's not. This will make sure that our open issues are actually of use and reduce the list of obsolete issues. Thank you for your contributions.