search

TiddlyWiki / TiddlyDesktop

A custom desktop browser for TiddlyWiki 5 and TiddlyWiki Classic, based on nw.js
1.72k stars 121 forks source link

Add GitHub Actions workflow to build TiddlyDesktop #289

Closed rmunn closed 8 months ago

rmunn commented 8 months ago

This workflow is only minimally tested: I ran it locally (using https://github.com/nektos/act) and verified that it could create tiddlydesktop-*-v0.0.18.zip files, but I did not find an easy way of testing them. You may (and probably will) want to tweak it, but this might be helpful as a first step towards getting an automated release process set up for TiddlyDesktop.

One way this might be improved, for example, would be to have all six packages running in parallel on six different workers, rather than one at a time on a single worker. I haven't tried to do that in this sample, as that would involve changing the way the bld.sh script works. But it would be pretty straightforward to do.

Jermolene commented 8 months ago

Thanks @rmunn that's terrific.

rmunn commented 8 months ago

If you're unfamiliar with GitHub Actions, my recommendation would be to create a scratch repository (mine is https://github.com/rmunn/Testing for example) somewhere and experiment. I recommend making it a public repo because private repos on free accounts only get 2,000 minutes per month of CI/CD time, and if you're experimenting with GitHub Actions it's surprisingly easy to run past that. (For example, when I run download-nwjs.sh it takes me an hour. If you have to tweak your workflow file ten times before you get it to work, and it takes an hour to run every time, that's 600 minutes out of 2,000 already gone).

The reason to experiment in a scratch repo is because when you're first getting started with GitHub Actions, it's a little tricky to get them to run in branches other than your default branch (i.e. master). Once you get the hang of it you can run actions from another branch, but at first it's just a lot easier to just push commits to master to re-run the action with the change you just made. And that ends up putting a lot of commits in your Git history that have nothing to do with the project code itself. So for repo history cleanliness, I prefer experimenting with GitHub Actions in a test repo and only adding the action to my real repo once I have all the bugs ironed out.

rmunn commented 8 months ago

@Jermolene - My latest commit turns this from a proof-of-concept into workflow for doing all the steps necessary that's pretty close to ready. The only problem it still has is that package.sh creates .zip files, but then when you upload those to the build artifacts, the GitHub Actions upload-artifacts step packages your upload into a .zip file. Yes, even if there's only one file and it already ends in .zip. And no, there's no option available (AFAIK) to turn that behavior off. So you end up with a .zip.zip file that contains a .zip file that contains the actual installer files, which is mildly annoying.

However, I just realised that that's not too important, because when you run the gh-release action, it will upload the files you specify to the release without changing them. So I can just add a gh-release step that creates a draft release and uploads the built files to the draft release, and they won't have the .zip.zip issue. Stay tuned for that, coming soon.

rmunn commented 8 months ago

@Jermolene - This is ready now. I've made quite a lot of changes to the build scripts, as you can see, but I've tried to make them still runnable from the command line in the same way they always used to be. (GitHub Actions sets the environment variable CI to "true" when running, so I use that environment variable to detect whether the script is being run by hand or not).

When the scripts are being run from GitHub Actions, they build all six versions of TiddlyDesktop in parallel using the matrix strategy, which defines different variables for each run, and the workflow can then use those variables to change behavior accordingly. For example, I have both the Linux and Windows builds run on GitHub's Ubuntu runner because it's faster than their OS X runner. But the Mac builds run on the OS X runner because it has the xattr command that the Ubuntu runner doesn't have. (Linux has chattr but I wasn't sure if it would set Mac extended attributes correctly or not, so I used the Mac runner for the OS X builds, even though it's slower so those builds are always going to be the last to finish).

You can see a successful run at https://github.com/rmunn/TiddlyDesktop/actions/runs/8121507798 and download the build artifacts from there. I deleted the release that that run created because I didn't want anyone to stumble across it and think it was an official TiddlyDesktop build, but before I deleted it I tested it and verified that the release doesn't have the .zip.zip problem I mentioned in https://github.com/TiddlyWiki/TiddlyDesktop/pull/289#issuecomment-1974666809. So this is ready to merge.

Once this is merged, you'll be able to create a release by tagging a commit v#.#.# (e.g. v0.0.19) and then pushing that tag.

Jermolene commented 8 months ago

Many thanks @rmunn, this is a tour de force, wildly above my own GitHub Actions skills level. It is much appreciated, and will be very useful. I'll merge now, and then will try making a new release in a moment.

Jermolene commented 8 months ago

Hi @rmunn I made a new release using the button at the top of https://github.com/TiddlyWiki/TiddlyDesktop/releases, and created a new tag for the release. Will the build products automatically be added to the release?

Jermolene commented 8 months ago

Will the build products automatically be added to the release?

The answer is "yes" – everything seems to have worked as expected: the build products are now listed as part of the release:

https://github.com/TiddlyWiki/TiddlyDesktop/releases/tag/v0.0.19

I'm just testing the macOS release now.

Thanks again, much appreciated.