but the tests (make testfront) segfaults

Oh dear, just like CircleCI. :-/

but the tests (make testfront) segfaults

Oh dear, just like CircleCI. :-/

and here i thought it was my fault :)
I am using 0.1.8 for now to make sure it works.
For the future is there any reason we are using 18.04 (bionic) instead of 20.04 (focal) in the docker image?

For the future is there any reason we are using 18.04 (bionic) instead of 20.04 (focal) in the docker image?

Yes, upwards compatibility is better than downwards. That applies for the Debian packages as well as the AppImage. They'll be compatible with basically everything newer than Ubuntu 18.04/Debian 10.

https://docs.appimage.org/introduction/concepts.html#build-on-old-systems

As a corollary, I'd like people to pick up hacking the project as easily as possible, i.e., without having to download a custom brand new CMake or some such.

Of course that's only a general guideline. Ubuntu 18.04 ships with CMake 3.10 and there are definite reasons to prefer at least 3.13 (and if you do that you might as well go straight for 3.16, which is a commonly backported version). But unless there are concrete advantages, the older the better, so to speak.

Also keep in mind @NiLuJe runs the very latest of everything, I tend to be a touch more conservative with currently Debian 11 and Kubuntu 21.10 but, ya know, it's not Debian 10 or something ;-) so the CI also ensures it actually won't break on those older systems. We already test on newer ones ourselves.

Ok, it works now with 0.1.8
Now i need to figure out the cache permissions

and here i thought it was my fault :)

Nah, I thought #7775 was just a small change but it's been on hold because I don't know what might be going wrong. Running the same thing in Docker locally doesn't produce any segfaults on any of my systems.

PS I just realized I forgot to use a newer busted in the 0.2.2 Docker images; normally I'm not in a rush when putting them together.

Base cache works :)
the install cache causes busted to error

Run .ci/test.sh
************ CMAKE_MAKE_PROGRAM: "/usr/bin/ninja" **********
ln -sf ../../.busted koreader-emulator-x86_64-linux-gnu/koreader
# sdr files may have unexpected impact on unit testing
rm -rf spec/unit/data/*.sdr
cd koreader-emulator-x86_64-linux-gnu/koreader && ./luajit /home/ko/.luarocks/bin/busted \
	--sort-files \
	--output=gtest \
	--exclude-tags=notest  
/bin/bash: line 3:  2348 Illegal instruction     (core dumped) ./luajit /home/ko/.luarocks/bin/busted --sort-files --output=gtest --exclude-tags=notest
Makefile:138: recipe for target 'testfront' failed
make: *** [testfront] Error 132
Error: Process completed with exit code 2.

Cached action takes ~6min to run

@Frenzie
The basics of this PR work, but i am losing hope for getting the new docker images working.
@NiLuJe
Could luajit be giving illegal instruction errors because the different cloud machines have different --march=native, so when it is cached between runs it fails?

@yparitcher There should be a similar mechanism as in CircleCI to prevent that. Note the {{ arch }}. I'm fairly sure dumping the cache was also one of the first things I tried when I first saw this issue in CircleCI (not because of different arch, see above, but because of the different compilers in the Docker images). I can experiment with that some more if you like; I shelved it in favor of this PR.

That's an interesting thought, yeah. Might be worth trying to force a dumb -march=x64 (or whatever the actual sane lowest common denominator is ;p).

The translations/docs require a PAT to be able to commit to a different repo
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
https://docs.github.com/en/actions/security-guides/encrypted-secrets
I don't have admin access to try to create one.

Bus factor - 1.

Bus factor - 1.

With great power comes great responsibility.

Yup! :-)

See koreader/doc#1 for a GHA that will allow us to triiger a doc build without having to pass around secrets

@Frenzie
@ anyone who can help with security :)

github action are run with a GITHUB_TOKEN that only has permissions in the current repo.
In order to commit in a different repo on can:
make a user PAT, however the drawback is that if the person leaves the org it will stop working, and there are no ganular permissions, the PAT an access any repo of the user.

With a organization Github Apps one can give the app only repo permissions and these permissions will only be applied to the repos the app is installed to.

Based on the above, I have a few questions/ suggestions.

1. I would like to make a "commit" Github App and install it in the doc and translation repos. this can then be used by a workflow in the koreader repo to commit with the auth of the app. For details see this blog post and my sample action
2. Can we change the default permission for the GITHUB_TOKEN to read only as i don't think we are using github actions anywhere to write
3. Do we still use Travis anywhere in the org? If not can we Deauth its third party integration?

BTW even with the 0.1x it still the test still fail intermittently with "illegal instruction", so if someone can figure out how to make a generic x64 build it would be nice to test.

Edit: weirdly the action run on my fork for the same commit succeeded

Do we still use Travis anywhere in the org? If not can we Deauth its third party integration?

Yes but also no. Travis committed suicide and while you'd think the new Travis would be a drop in replacement it either isn't or it just doesn't work for me. But in any case travis*.org* is defunct.

Put another way, there are some things not converted to GHA yet.

@yparitcher DEBIAN=1 ./kodev build should do that, shouldn't it?

superseded by #8428