Switching to GitHub Actions

[ErikBjare]

So I've been playing with this in #382, and I'm impressed.

Motivations:

• Better build times (especially for macOS and Windows), see Improve CI build times #370.
• Integrated into GitHub, better UX in general
• Easier/cleaner config (especially with regards to multi-platform support)
• Seems more reliable
  • Not a high bar to beat
  • Travis has had outages, build backlogs, builds stalling
  • I've been getting "An error occurred while generating the build script." frequently recently (the last two days) for macOS builds.
• It makes us able to finally get rid of Appveyor and unify our CI process
• It allows for more advanced automation, such as automating creating releases with changelog and everything.

I'm seriously tired of mucking with Travis and Appveyor, especially due to the long build times, so pretty excited about getting this done, so we can scrap them.

Subtasks before ready to completely migrate to GitHub Actions:

• Upload build artifacts on every build
• Upload releases to GitHub releases
  • Can even automate the creating of the release, including generating the release description & changelog. See: https://github.com/actions/upload-release-asset
• Add caching for aw-server-rust/target
• Build aw-server-rust in debug mode on non-releases (for faster builds), see added RELEASE option to Makefile (for faster non-release builds) aw-server-rust#100
• Test builds on all platforms
  • Linux
    • Problems found, see comments.
    • Fixed in ci: install Qt & xcb libs in CI environment #604
  • Windows
  • macOS (done in Switching to GitHub Actions #388 (comment))
    • Problems anticipated on versions of macOS older than the version used in CI, probably need to do some xcode-select magic (done in 9f0f7c7)
      • Stumbled into some issues... Might work now, but should check with otool to be sure: https://stackoverflow.com/questions/17143373/determine-minimum-osx-version-a-binary-was-compiled-for (done in ci: updated PyInstaller and dev locks, added Python 3.8 and 3.9 as experimental #544 (comment))

Progress on moving module repos to GitHub Actions:

• aw-server (ci: switched to GitHub Actions for CI aw-server#73)
• aw-server-rust
• aw-webui
• aw-qt (ActivityWatch/aw-qt@20261da)
• aw-core (ci: switched to GitHub Actions aw-core#89)
• aw-client (ci: switched to GitHub Actions (and more) aw-client#51)
• aw-watcher-afk (ActivityWatch/aw-watcher-afk@4b9eea5)
• aw-watcher-web (ci: added basic CI aw-watcher-web#63)
• aw-watcher-window
• activitywatch.github.io (Switch to GitHub actions for deployment activitywatch.github.io#13)

An overview of migration progress can also be seen on the CI overview page

[ErikBjare]

Testing the Linux build gives me SIGSEGV as soon as I right-click the tray icon:

(lots of similar lines above)
Fontconfig warning: "/etc/fonts/conf.d/90-synthetic.conf", line 5: unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 5: invalid attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 5: invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 6: invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 6: invalid attribute 'version'
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Fontconfig warning: FcPattern object weight does not accept value [40 210)
fish: “./aw-qt --testing --autostart-m…” terminated by signal SIGSEGV (Address boundary error)

Testing a recent version from Travis gives me similar Fontconfig error/warnings (and super ugly font in the tray icon menu), but doesn't SIGSEGV.

[xylix]

Did you try rebuilding the qt reaources after changing pyqt version?

[ErikBjare]

@xylix They are built in CI, nothing to rebuild.

[johan-bjareholt]

A bit of a shame to get even more locked into the GitHub ecosystem, but considering how much of an improvement it seems to be and the time spent it seems to definitely be worth it.

[ErikBjare]

A bit of a shame to get even more locked into the GitHub ecosystem

I agree, but to be fair GitHub has been doing a lot of things right recently (apart from closing repos because of US embargoes, but their hands are tied) and at this point they are the ecosystem (with the acquisition of npm, semmle, dependabot, etc).

[johan-bjareholt]

at this point they are the ecosystem

Disagree, but that's off topic I guess.

[ErikBjare]

As @xylix mentioned on Discord, Travis will start charging for macOS instances, so we'll have to migrate at least the macOS builds pretty soon.

[ErikBjare]

Just tested the latest GitHub Actions macOS build (from master), works fine.

Edit: It worked fine in Catalina, but otool reported 10.15 as minos so would probably not work on Mojave. I think I managed to fix it in: #544 (comment).

[ErikBjare]

Found a couple of hints for the SIGSEGV on Linux:

• WIP: PyQt app built on Ubuntu 18.04 on Gitlab CI fails on Fedora 32 pyinstaller/pyinstaller#4985
• pyqt5-based app build on Centos 7 fail to run on Ubuntu 18.04 or recent Fedora pyinstaller/pyinstaller#4970

I can for example run this without issue, although no trayicon appears:

env QT_QPA_PLATFORM=minimal \
	QT_DEBUG_PLUGINS=1 \
	LD_PRELOAD=/usr/lib64/libfreetype.so:/usr/lib64/libfontconfig.so \
	./aw-qt --autostart-modules 'none'

But this fails:

env QT_QPA_PLATFORM=xcb \
	QT_DEBUG_PLUGINS=1 \
	LD_PRELOAD=/usr/lib64/libfreetype.so:/usr/lib64/libfontconfig.so \
	./aw-qt --autostart-modules 'none'

With the output (truncated):

...
Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/home/erb/Applications/ActivityWatch/activitywatch/platforms" ...
loaded library "/home/erb/Applications/ActivityWatch/activitywatch/PyQt5/Qt/plugins/platforms/libqxcb.so"
loaded library "Xcursor"
fish: Job 1, 'env QT_QPA_PLATFORM=xcb  QT_DEB…' terminated by signal SIGSEGV (Address boundary error)

Might just be missing libs, attempting fix in #604

[ErikBjare]

#604 worked!

Looks like we are good to go! (assuming the Windows build is fine)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ErikBjare]

This was completed a while back. Nice to finally be done with it.