The Terraform Pulp provider helps you manage Pulp resources using Terraform. It supports most features provided by Remotes, Repositories, and Distributions for any content type supported by Pulp. The provider is compatible with Pulp 3.x.
See: Official Documentation in the Terraform registry.
Some features may not be included in the provider yet. If you are missing a feature, please open an issue or fork the repository and reference the fork in your issue.
Instead of having different resources for each content type, the provider uses a generic resource for each Pulp resource type.
provider "pulp" {
server_url = "https://pulp.example.com"
username = "admin"
password = "<password>"
}
resource "pulp_remote" "docker" {
name = "docker"
content_type = "container"
plugin_name = "pull-through"
url = "https://registry-1.docker.io"
}
resource "pulp_distribution" "docker" {
name = "docker"
base_path = "docker"
content_type = "container"
plugin_name = "pull-through"
remote = pulp_remote.docker.pulp_href
}- Clone the repository:
git clone https://github.com/e-breuninger/terraform-provider-pulp- Change into the provider directory:
cd terraform-provider-pulp- Build the provider:
go installCommits follow Conventional Commits. The version and the changelog are derived from them, so the type matters.
Install the hooks once to catch a malformed message before it is written:
pre-commit installCI checks pull requests too. A local hook can be skipped, and a fork never ran it.
Releases are cut deliberately, not on every push. Nothing in CI bumps the
version or writes CHANGELOG.md:
make release-dry-run # what would the next version be?
make release # version, CHANGELOG.md, commit and tag
git push --follow-tags # this is what starts the buildThe version comes from the increment the commits imply, applied to the highest
tag in the repository. Taking the highest tag rather than the highest one
reachable from HEAD means a release can never reuse a version, even if an
earlier tag was stranded by a rebase.
Run this on master, after merging. Commitizen tags the commit it writes
CHANGELOG.md into, so a release cut from a feature branch leaves the tag
pointing at a commit master never gets. make release refuses to run
elsewhere, and the Release workflow refuses to publish a tag that is not on
master.
Pushing the tag starts the Release workflow, which builds the provider and
publishes it with release notes grouped by change type.
| commit type | effect |
|---|---|
feat: |
minor release |
fix:, perf:, refactor: |
patch release |
! or BREAKING CHANGE: |
major release |
| everything else | no release |
make release reports that nothing warrants a release when only types in the
last row have landed. Use ci: or build: for pipeline and test-harness work.
fix: claims a provider bug was fixed, and bumps the version for a change
users never see.
This Provider focuses on the most common use cases for Pulp. We focus on Pull-Through Caches for Maven, PyPI, NPM, and Docker, and may not support all features of Pulp. If you are missing a feature, please open an issue or fork the repository and reference the fork in your issue.
This project uses AI to assist in code generation and documentation. The AI is used to generate code snippets, documentation, and other content based on the context provided by the developers. The AI is not a replacement for human developers, but rather a tool to assist them in their work.