pulp / pulp/pulpcore

As a user I want to have content logically connected/grouped across plugins

Open
#3,710 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Feature
Dominant language
Python
Stars
598
Forks
168
Avg merge
1d 4h
Merged PRs (30d)
86

Description

Is your feature request related to a problem? Please describe.

Yes, the problem comes around from a situation like:

I have a set of rpms stored in the rpm repos, from which I am going to build an ISO or qcow image or a container.
Built image(s) are going to be uploaded as an arbitrary file into pulp_file plugin and/or container registry.
Next in my pipeline I'd like to test the built image(s) by running them through various CI testing gates, results and logs from which I'd like to also store.
As a result of my workflow, I'd like these artifacts stored across plugins (rpms, image built form rpms, test results, any other arbitrary build metadata) ideologically related to the same set of content be logically united or grouped, for example via a repository group( or some other means), so later on I can decide to atomically whether delete all or promote the content depending of different CI criteria or policy I have in place.

Describe the solution you'd like
I'd like to have a way to connect or group content of different nature(across plugins) under one hood.

Describe alternatives you've considered
Store somewhere the information that rhel8_rpm_repo's content is incorporated into rhel8_iso_repo and rhel_8_iso_test_results_repo are grouped so if my CI tests do not pass I can in one go delete all these (by manually issuing multiple API calls across plugins) or, viceversa, promote ( in a similar way)

Additional context
Add any other context about the feature request here.

cc @bookwar

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by turning the cross-plugin grouping workflow into a concrete design with acceptance criteria for atomic deletion and promotion; done means the approach and its behavior across RPMs, images, test results, and metadata are specified.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.