# 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