Pulp CLI Meeting Minutes

The Pulp CLI meeting is the place to discuss features and issues that will affect the pulp-cli codebase. It’s mostly attended by pulp-cli committers, but anyone interested in pulpcore can come.

When

Usually every second week Wednesdays at 15:30-16:00 Central European (Summer) Time.

Where

On Google Meet
Video call link: https://meet.google.com/dvi-ebyc-zoj

Agenda

Anyone can add to the agenda.

Aug 19

  • pulp-cli-deb
    • Introduction to quba42
    • transfer of the repo to pulp namespace; adding the pulp/debian team
      • [mdellweg, davidd]
    • upload to PyPi; add quba42 to that package
  • pulp_rpm workflow docs still use httpie
  • Docs day
    • General organization (structure, outline); probably before docs day
    • Get the user started; point to workflow docs
      • dev-user-hat needs “pip install -e .”
      • pip-comfortable user needs pip-install
      • rpm-comfortable user needs to know how to dnf-install
    • Improve “how to add commands”
  • Reminder: self-assign issues or check issue assignment
    • unassignment is possible
    • check that github correctly links PR and issue
    • assign issues to next-milestone please?
      • can we do this as part of the merge-workflow?

Sep 1

  • Certguard plugin
    • should certguard commands be separate from core package?
    • how to deal with commands placement
      • pulp content-guard rbac … +1 +1+1
      • pulp cert-guard -t rhsm …
  • 3 month planning in 2 weeks
    • some FTEs may be freed up - do we want to raise cli-prio?
      • content for rpm/ansible?
      • ggainey AI - submit PR to generalize string/@ behavior
      • filtering (for existing cmds) would be good
      • field-selectivity can wait since you can be selective w/ jq after the fact

Sep 15

  • Nightly test is failing
  • Where to add ostree support?
    • No strong opinions
    • pulp_deb would like to see another external plugin
      • To improve support of external plugins

Sep 29

  • Reviewers: Please make sure every new user facing string gets a _().
    • Also we should gradually fix all the others we stumble over.
  • State of the translation experiment
  • We are currently testing the CLI with pulpcore 3.11 - 3.15. Are we ready to drop any workarounds for <=3.10 ?
    • Should we also install a global needs_plugin("core", "3.11") so users are aware and may use older versions?
      • make sure we can at least update the cached-schema if current is “too old” to run the command
      • the only significant potential consumer of pulp-cli pre-core-3.11 is Sat6.9, which is using core-3.7.
      • the current pulp-cli functionality serves that need just fine
      • +1 for 0.12 advancing the pulpcore requirement to 3.11+
        • If needed desperately, we could make a 0.11 branch that even runs it’s CI with core-3.7 as a target and accept backport PRs
  • OSTree support - prob wants/needs to be its own package
    • see the current (incomplete) state of deb-support for an example
    • need an oci-image that includes ‘external’ plugins for testing

Oct, 13

  • Squeezer is currently built on the premise that it has no external dependencies, but reusing the openapi.py between the two projects may bring a lot of maintenance benefit. What would be the impact of having the squeezer collection depend on pulp-cli?
    • This may need more thinking about impacts.
    • No timeline for a change like this.
  • Should we rename the base branch to main?
    • Let’s do this for consistency
    • [mdellweg] to change the name. Done.

Oct, 27

  • different content is different (rpm) so it may need to go into different command groups
  • Pulp shell would be super useful if you could cd into a context
    • also capturing output for further processing would be nice
  • Yay feature matrix

Feb, 16

  • Implement automerge on approved PRs?
    • Approve must be final
    • A change must dismiss any approval
    • request-for-change must be able to be reset/accepted by :the next reviewer", whoever that is
    • and the approving-reviewer is on the hook to do it!
      • Rules for auto-merge:
        • 1 approval
        • CI is green
        • no merge-conflicts
        • PR not in draft
    • if approved, and PR author removes Draft - automerge immediately?
    • Can we agree on a standard for “DO NOT APPROVE/MERGE THIS” in PR commit-message?
    • if applied in check-pr workflow, needs to reject merging AFTER CI runs
      • so it doesn’t cancel CI like lint does
    • Timeline/to-do
      • x9c4 to experiment
      • switch next Weds 23-FEB?
  • Discussion RE container and differences in some commands from other plugins
    • Example: modify allows base-version, but NOT in container
    • should the command-name be same, even when “standard” arguments are not?
    • OR should command-name be plugin-specific even when most args are similar?
    • gerrod to sync up w/ ipanova to discuss and bring back to next mtg

Mar 02

  • automerge discussion
    • disappointed in GH
    • will leave AM turned on (does no harm)
    • dismissal of reviews on change will be kept on
    • takeaway: be agressive about pushing the merge button
      • if it’s green - Do It!
      • whoever pushes the button, isn’t liable for bad reviews
      • still implies "do not Approve PR unless you’re willing for it to be merged immediately "
  • What about a Release 0.14.0? Yes!
    • moved outstanding issues to 0.15.0