Start GitHub action workflow #56
Conversation
ballessay
force-pushed
the
github-action
branch
2 times, most recently
from
8792d2d to
b2a141b
Compare
ballessay
force-pushed
the
github-action
branch
from
b2a141b to
b225f92
Compare
|
Should be ready now for merge. There is on hacky build step regarding the translation files, but I didn't want to investigate linuxdeploy further at the moment and it seems to work fine this way. Another thing I don't really like but wasn't sure I should change it is the AppImage name, which seems to be generated/deducted by the name in |
Use github actions as CI tool. Build the code and create and release on AppImage on tags.
ballessay
force-pushed
the
github-action
branch
from
b225f92 to
57d9071
Compare
luebking
left a comment
luebking
left a comment
There was a problem hiding this comment.
Idk how appimages typically handle this, but if the startmenu etc. token is "Phototonic", the equal appimage name seems reasonable?
| - name: Build | ||
| run: make -j $(nproc) | ||
|
|
||
| - name: Update and create translations |
There was a problem hiding this comment.
There're precompiled translation modules in the git repo.
There was a problem hiding this comment.
Okay. But why? (Referencing the Ryan Reynolds meme image. It's completely normal to update and generate them in a build pipeline. ¯_(ツ)_/¯
There was a problem hiding this comment.
Dunno. Was like this when I showed up and didn't saw a reason to change it.
I'll say that the linguist tools tend to draw in Qt dependencies one otherwise might not need, so it's probably nice for individually building users.
| - name: HACK - symlink translation files (linuxdeploy fails to do so) | ||
| run : | | ||
| pushd . > /dev/null | ||
| mkdir -p AppDir/usr/translations |
There was a problem hiding this comment.
Do you know whether AppDir/usr is either QM_FILES_INSTALL_PATH or QTDIR ?
Maybe the qmake should simply not hardcode the destination…
There was a problem hiding this comment.
Not yet. But I just had a look into the .pro and maybe the hardcoded *.path entries a the culprit. I'll do a bit of testing and rereading the qmake documentation.
Yes, it seems that way. With a quick search I found this (another appimage tool but I guess they work the same) |
2 participants
Builds the project on different triggers/branches and creates an AppImage which will be uploaded to the GH relases page on tags.
Note: the missing header commit is included here to get a successful build