---
# System prepended metadata

title: CI Notes

---

# CI Notes

## Goals:
* [DONE] Release Pulpcore once a week (at least).
  * For literally "no changes" we don't need to.
  * Only bump the new version if there are features.
* [DONE] Have plugins in a state that they can release at any time.
  * Don't integrate with source versions.
* [LOW PRIO]Update CI workflow can also run the black (formatting) version from dev_requirements.txt.
  * This could be turned into a reusable workflow.
  * Nice to have, does not save a lot of work.
* Make the CI runnable as a local user.
  * Max 3 commands.
    * `*-compose up`
    * `make test`
    * using the pulp-minimal images with a plugin specific build step in compose
* Pull request and Nightly CI should only differ by which tests are run. No publishing of docs (or anything) on nightly.
  * linting should not be on nightly
* [DONE] Release pipeline should not need to run tests before publishing packages.
  * The main branch is constantly ready to release.
* [MID PRIO] Clean nightly published Clients from PyPI and rubygems.

## What is the CI supposed to do?
1. Check commit message and requirements files (ready to ship)
2. Lint the code
3. Build a Pulp container (with pulpcore or plugin from source and additional plugins from pypi)
4. Start a Pulp with that container
  - In several different scenario (storage; rerouted).
5. Build bindings for all pulp components in that container
6. Install test dependencies and bindings
7. Run functional tests from multiple components
8. Run unittests, ideally in only one runner/scenario

## Ideas:
* Use docker/podman-compose to spin up the stack.
  * Separate files for different scenarios.
      * Separate compose files and separate settings files that provide storage configs.
* Can we reuse the container images across workflows/jobs?
* Add `extras_require` with "ci", "test", "lint" keys to plugins.
  * `pulp_file[ci]` would depend on `pulp-certguard` for example.
  * `pulp_file[test]` would depend on `pytest`, `pulp-certguard-client` and `pulp_file-client`.
    * This needs to be installed later because the client must be built. (Does it?)
    * How can we ensure that the client matching the server plugin version is installed? (The old bindings issue)
      *  Can we switch all tests to use pulp-glue?
* Are we ready to use the cli for easy ci workflow decisions?
  * Is plugin ??? installed?
* How do we know what tests to run when we do not have additional_repos anymore?


# pulp-oci-images

Add a service container to the compose that will 
* run migrations
* sets admin password
* add signing services
* Uses the same pulp-minimal image

Remove all the extra stuff from the pulp-api commands
Remove the wait for stuff from pulp-content and pulp-worker commands
Allow the command of the container to pass on additional parameters to the application entry point


