There is no reason to publish nightly for all project we try to build
in the CI.
We should publish nigthly for same project that we do for releases.
(Minus the filter of what have changed since last release)
Fix#743
As we build the "same"[*] things with build_project and build_release_nightly,
let's use the same code.
[*] We are not building the same things has we don't run the same runners
(not the same `PLATFORM_TARGET`) but for a given `PLATFORM_TARGET`, we
are building the same things.
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.
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
renaud gaudin
Alexander Sashnov