Both the fallback and the passed ref were targeting the master branch of those repositories.
This triggers the workflow on their main branch and sets the default target branch to main as all our repositories use it.
The `INSTALL_DIR` was added twice. It was not a issue as we then transform
the list into a set to remove duplicated.
But with `filter_install_dir` call only on one "add", the (textual)
entries are not duplicated and so, not removed. So the files where add
twice.
Now we correctly filter initial `INSTALL_DIR` and we remove the second add.
`icu4c_wasm.patch` is build by :
- Copying config.sub from liblzma source as new version of config.sub there
knows about wasm architecture.
- Copying `mh-linux` on `mh-unknown` as specified in (origin) `mh-unknown`.
This is because icu4c configure doesn't detect `emscripten` platform and
"fallback" to `mh-unknown`.
By uploading read-only archive, we prevent potential (implicit) re-upload.
A re-upload will always be possible if we remove the archive and rerun
the workflow. But it will be clearly explicit in this case.
While it is ok to build all libkiwix android builds in one step,
the "release system" upload only one archive per platform.
So we need 4 platforms to do 4 uploads.
As we don't build on "android" platform now, we can clean up our scripts.
When build_release_nightly calls codesign to sign libzim.7.dylib, it appears to be
hanging forever.
What's most likely happening is that Keychain Access is prompting a password request
without any possibility to answer, given this is running on the CI.
It's unclear whether Keychain Access wants to confirm codesign can access the certificate
or if it is trying to unlock another (System) keychain to find the certificate or key.
This addresses the former.
SSH server which was used to receive file uploads (CI, nightly and release) has been
migrated to a new one on a different address.
Username, Key and paths are unchanged.
Most notable changes are the use of `master.download.kiwix.org` as the target in
replacement of `mirror.download.kiwix.org` (although it would still work) and the
Port to which SSH is listening on (30022 instead of 22)
This adds the notarization (see #469) of the libzim binary for macOS during the build.
It it not dependent on RELEASE so it benefits all builds.
It basically does two things:
- sign the build with our Developer ID certificate from Apple.
- Request notarization from Apple for the binary.
At the moment, it concerns only libzim. Might expand that to libkiwix and the zim/kiwix tools
once we start releasing those.
Github Actions prepare the certificate and environment, and signing+request is done in `notarize_macos_build()` (common.py)
It required the following new secrets:
| secret | value |
|---|---|
| `APPLE_SIGNING_CERTIFICATE` | base64 of the P12 certificate |
| `APPLE_SIGNING_P12_PASSWORD` | password for the P12 certificate (we chose that when exporting to P12. Apple doesnt provide P12) |
| `APPLE_SIGNING_IDENTITY`| Common name of our certificate. Not a private info but seems better suited there than in the CI |
| `APPLE_SIGNING_TEAM`| Apple Developer Team ID (mentionned in the signing identity) |
| `APPLE_SIGNING_ALTOOL_PASSWORD`| app-specific password created to request notarization |
| `APPLE_SIGNING_ALTOOL_USERNAME`| username associated with the app-specific password. Must be an Apple ID with perms on the Certificate. Currently mine. |
This triggers a `workflow_dispatch` event on the `docker.yml` workflow or the matching
repository for both `zim-tools` and `kiwix-tools` targets that supports it.
Issue #349 requires a native_mixed for macOS.
native_mixed is working for libzim so we whitelist it.
On the release CI, we fix the macos dylib rpath so it doesn't include the
full build-install step path which is probematic for a distributed file.
We build native_mixed for OSX in both CI and release mode
Matthieu Gautier
Emmanuel Engelhart
renaud gaudin
renaud gaudin
Alexander Sashnov