fedpkg

#137 Wrapper of fedrepo_req
Closed: Fixed Opened by cqi.

Closed: Fixed
Reopen Issue

As discussed with @mprahl, there is a new requirement of integrating fedpkg with fedrepo-req, that fedpkg as a wrapper of fedrepo-req to allow packagers to request new repository and branches from one consistent tool.

Basically, for the first version of this integration, fedpkg is able to request a new repository in these ways

  • request a new repository with or without a new branch, and package review bug ID should be specified
fedpkg req-repo [options] repository_name [branch name]
fedpkg req-repo --review-bug 12345 nethack
fedpkg req-repo --review-bug 12345 nethack epel7

In addition, option -n and --namespace can be specified to pass repository's namespace, which is same as fedrepo-req-branch and valid values are rpms|container|modules|test-modules.

  • allow specify service level for branch
fedpkg req-repo --review-bug 12345 --sl security_fixes:2022-12-01 --sl bug_fixes:2022-12-01 nethack lts

Obviously, req-repo does not need to run from a git repository.

Then, fedpkg is able to request new branch for a repository. Similarly, two ways with service level specified or not. Like

fedpkg req-branch [options] [repository name] branch
fedpkg req-branch nethack epel7
fedpkg req-branch --sl security_fixes:2022-12-01 --sl bug_fixes:2022-12-01 nethack lts

In addition, option -n and --namespace can be specified to pass repository's namespace, which is same as fedrepo-req-branch and valid values are rpms|container|modules|test-modules.

Command req-branch can run from a cloned package repository or not. Latter case is for requesting new branches before repository request issue is handled.

UPDATE:

Preferably support all fedrepo_req options.

It would be nice, if there is some discussion about the CLI UX.

Honestly, "req-branch" or "req-repo" are not rememberable names. "request-*" would be better, but why there are two commands anyway? From my POV, there is no difference in asking for "master" branch or for "27 and master"

Also, providing the name of the package should not be needed at all. fedpkg should have enough context already from the directory or the BZ ticket ...

Honestly, "req-branch" or "req-repo" are not rememberable names. "request-*" would be better, but why there are two commands anyway? From my POV, there is no difference in asking for "master" branch or for "27 and master"

+1 to request-*.

My original thought is request-branch could run inside a package repository or not. So, in former case, request-branch would make sense and repository name can be inspected from repository directly.

Also, providing the name of the package should not be needed at all. fedpkg should have enough context already from the directory or the BZ ticket ...

I think it makes sense. So the user story would be

As a packager I want to request branch for a new repository and if I do not provide the repository name, it should be detected from my package review bug summary.

What would be the use case of "from the directory"? I can imagine and guess two,

One is I create a directory locally and I request package repository and branches inside this directory.

Another one is I've cloned my package already, and I want to request other branches inside this package repository.

Both, one of them, or anything else?

I have a bit of "free time", so I'll tackle this work this week if there are no objections.

@mprahl Feel free to go :thumbsup: Thank you :smile:

I don't see a use case that would require the package name. Either you are requesting a new repo, in which case the name is in the review bug, or you are requesting a new branch which can be retrieved from the cloned repo and you can get the name the usual way from clone url or whatever.

However if you want to be able to override it, would it make sense to use the same --module-name global option that other commands use?

@lsedlar it's because packagers often request the repo and then subsequently request the branches without waiting for the repo to be approved and created. It's just simpler this way.

I forgot to mention, PR #170 ports the fedrepo-req and fedrepo-req-branch functionality to fedpkg.

Metadata Update from @cqi:
- Issue set to the milestone: NEXT

@cqi can you close this issue now?

Yes, thanks for reminding :)

Metadata Update from @cqi:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @onosek:
- Issue set to the milestone: None (was: NEXT)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.