70 lines
3.7 KiB
Markdown
70 lines
3.7 KiB
Markdown
# Krita dependencies management repository
|
|
|
|
## Links
|
|
|
|
- fork of ci-utilities repository: https://invent.kde.org/packaging/krita-ci-utilities
|
|
- ci-images repository: https://invent.kde.org/sysadmin/ci-images
|
|
- artifacts:
|
|
- Windows: https://invent.kde.org/teams/ci-artifacts/krita-windows
|
|
- Linux: https://invent.kde.org/teams/ci-artifacts/krita-appimage
|
|
- MacOS: https://invent.kde.org/teams/ci-artifacts/krita-macos
|
|
- Android-arm64-v8a: https://invent.kde.org/teams/ci-artifacts/krita-android-arm64-v8a
|
|
- Android-armeabi-v7a: https://invent.kde.org/teams/ci-artifacts/krita-android-armeabi-v7a
|
|
- Android-x86_64: https://invent.kde.org/teams/ci-artifacts/krita-android-x86_64
|
|
- Notary service repository: https://invent.kde.org/sysadmin/ci-notary-service
|
|
- Configs for the notary service: https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/signing
|
|
|
|
## CI job names structure
|
|
|
|
All publicly available CI jobs have names in the following format:
|
|
|
|
```
|
|
<target_packages>_<build_type>_<platform>
|
|
```
|
|
|
|
`<target_packages>` defines what packages are going to be built in this job. It may have the following values:
|
|
|
|
- `all` --- the job builds all the packages available in the repository, including the debug and asan versions of the packages
|
|
|
|
- `custom` --- the job builds only the packages passed via the web gui. To pass the space-separated list of packages, click on the job and set up the following job input:
|
|
|
|
- input: `KRITA_STAGE_DEP`
|
|
- value: `base/qt base/mlt` (space-separated list)
|
|
|
|
- `dirty` --- the job rebuilds a subtree of "dirty" packages. Basically, it rebuilds the passed packages and all their dependencies. The list is passed via `KRITA_STAGE_DEP` input like for "custom" packages.
|
|
|
|
`<build_type>` defines what happens with the package after the build is done. It may have the following values:
|
|
|
|
- `publish` --- after the build the packages are published to the repository; publishing is allowed in protected branches only, so if you try to build multiple packages in a non-protected branch, the job will most probably fail
|
|
|
|
- `local_cache` --- after the build the packages are uploaded into the local cache. This method is suitable for non-protected branches and merge requests to test the changes in the build process
|
|
|
|
- `shared` --- this is the legacy method of building multiple backages in the same environment without uploading them into the package repository. Currently, it is available for debugging purposes only
|
|
|
|
`<platform>` selects the platform for which we build the package
|
|
|
|
## How to update/rebuild a dependency
|
|
|
|
### Testing the changes
|
|
|
|
1. Change the build recipes in `ext_foo` directory
|
|
2. Create a branch/MR with the changes
|
|
3. Open the auto-generate pipeline for the branch/MR
|
|
4. Depending on the nature of your changes you may prefer to rebuild one specific package or a whole subtree of dependencies. To do that you need to open a corresponding job (open it by clicking on a name, **not** on the "play" button):
|
|
|
|
- rebuild a single package: open `custom_local_cache_<platform>`
|
|
|
|
- rebuild the sutree of deps: open `dirty_local_cache_<platform>`
|
|
|
|
Note: you need to use "local_cache" type of job, since publishing is not available from non-protected branches.
|
|
|
|
5. On the job's page set the job input:
|
|
|
|
- input: `KRITA_STAGE_DEP`
|
|
- value: `base/foo base/bar` (space-separated list)
|
|
|
|
6. After the environment variable is set, run the job to test if it builds fine.
|
|
|
|
### Publishing the packages
|
|
|
|
The packages can be published only from `master` and `transition.now/*` branches. After your MR is merged into master, you need to run `dirty_publish_<platform>` jobs for all related platforms to get the package published. The process of setting up `KRITA_STAGE_DEP` is the same as in the testing builds.
|