This is a command line interface for Pulp 3.
This software is in beta and future releases may include backwards incompatible changes.
pulp [<global_options>] <plugin> <resource_class> [--type <resource_type>] <action> [<action_options>]
Global options include:
--base-url
--user
--password
--config
--format
-v
/-vv
/-vvv
To install and use the CLI, run these commands:
pip install pulp-cli[pygments]
pulp config create -e
Read the installation and configuration doc for more information.
- Redirecting from
http
tohttps
, as done by a typical Pulp installation, does not work properly withPOST
andPUT
requests. Please usehttps://
in the base url. Note that the attempt to usehttp
leaks sensitive data over an unencrypted connection.
pulp status
pulp file repository list
pulp file repository create --name file_repo1
pulp file repository update --name file_repo1 --description "Contains plain files"
pulp file repository destroy --name file_repo1
The CLI uses the click package which supports shell completion.
To configure this, check out click's
documentation.
As an example, here is what to add to your ~/.bashrc
file if you're using bash:
eval "$(_PULP_COMPLETE=source_bash pulp)"
If you take the time to evaluate, test, or build your own CLI commands, please complete this survey, and we will gladly ship you some SWAG!
pulp-cli
comes with python type annotations and black code formatting.
To verify your code please run black
, flake8
, shellcheck
, and mypy
.
Run make lint
to check for compliance.
Also please follow The seven rules of a great Git commit message.
In order to be able to access every (sub-)commands help page,
it is necessary that no code outside of the final performing command callback accesses the api
property of the PulpContext
.
There are some facilities that perform lazy loading to help with that requirement.
Those include:
PulpContext.api
PulpContext.needs_version
PulpEntityContext.entity
PulpEntityContext.pulp_href
This cli for Pulp 3 will be versioned indedendently of any version of the server components.
It is supposed to be able to communicate with different combinations of server component versions at the same time.
So it might be needed to guard certain features / workarounds by the available server plugin version.
As a rule of thumb, all necessary workarounds should be implemented in the corresponding Context
objects to provide a consistent interface to the command callbacks.
Tests are shell scripts in tests/scripts
with names like test_*.sh
.
They should should focus on the cli operation and are not a replacement for pulp integration tests;
i.e. make sure the cli translates to the right api calls, but do not care about pulp internals.
In order to run tests, a running instance of pulp with all necessary plugins installed must be
configured in tests/settings.toml
.
To run tests:
make test # all tests
pytest -m pulp_file # tests for pulp_file
pytest -m pulp_file -k test_remote # run tests/scripts/pulp_file/test_remote.sh
- Generate the changelog (eg
towncrier --yes --version 0.1.0
) and commit - Run
bumpversion release
, commit your local changes, and note the commit sha - Run
bumpversion minor
to update the version to the next dev release version - Push your commits, open a PR, and get it merged
- After your PR is merged, pull the latest changes from develop
- Now tag your release commit (e.g.
git tag 0.1.0
) and push to pulp/pulp-cli - Monitor the build job and then check PyPI to make sure the package has been uploaded
- Send an email to pulp-list and pulp-dev to announce the release