Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enhance FedoraGitReleaser to build to all active Fedora branches #430

Closed
xsuchy opened this issue Nov 14, 2022 · 5 comments · Fixed by #476
Closed

enhance FedoraGitReleaser to build to all active Fedora branches #430

xsuchy opened this issue Nov 14, 2022 · 5 comments · Fixed by #476
Assignees
Labels
effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward RFE This issue is a Request For Enhancement (Feature)

Comments

@xsuchy
Copy link
Member

xsuchy commented Nov 14, 2022

I use this releasers.conf:

[fedora-git]
releaser = tito.release.FedoraGitReleaser
branches = rawhide f37 f36 f35

And it is pain to update it every 3 months because of new releases and new branching.

It would be awesome if I can use some magic to mark all active branches. E.g.,

branches = rawhide **fedora-active** **epel-active**

The list of active branches can be fetched from https://pdc.fedoraproject.org/ which has API.

@xsuchy xsuchy added the RFE This issue is a Request For Enhancement (Feature) label Nov 14, 2022
@FrostyX
Copy link
Member

FrostyX commented Nov 22, 2022

It would be awesome if I can use some magic to mark all active branches. E.g.,

branches = rawhide fedora-active epel-active

I am thinking of an alternative.

We can get the list of the active Fedora/EPEL versions here
https://pdc.fedoraproject.org/rest_api/v1/product-versions/

We can also get the list of branches for a package, e.g.
https://src.fedoraproject.org/api/0/rpms/copr-cli/git/branches
(or git fetch all)

So what if we make the branches = setting optional? And if not set, build the package for its every active branch?

@praiskup
Copy link
Member

The default behavior sounds OK to me, but I still think we should have the pattern-like solution on top of it.
E.g. have multiple releasers both in the mock and copr project. E.g. mock, in the main is built against all fedora + epel8+, but not against epel7.

@FrostyX
Copy link
Member

FrostyX commented Nov 22, 2022

This would IMHO work even with

So what if we make the branches = setting optional? And if not set, build the package for its every active branch?

Because this would basically build the package for all "Active branches" that are listed here

Which is IMHO the 99% of use cases. And I think it translates correctly for all Copr packages.

Of course, there might be packages that have their EPEL7 branch active but the packager no longer wishes to update it (maybe that's the case of Mock?). Such packages would continue listing the branches explicitly and I would suggest adding either exclude_branches option or something like branches = !epel7 or branches = -epel7 that would exclude from the default list.

What do you think?

@praiskup praiskup moved this to In 2 years in CPT Kanban May 11, 2023
@praiskup
Copy link
Member

praiskup commented Jun 3, 2023

Of course, there might be packages that have their EPEL7 branch active but the packager no longer wishes to update it (maybe that's the case of Mock?).

With Mock, we release from the upstream mock-2 branch into the Fedora downstream epel7.

something like branches = !epel7

That would work, yes :-)

@praiskup
Copy link
Member

Note for myself: curl 'https://pdc.fedoraproject.org/rest_api/v1/product-versions/?active=true' | jq

FrostyX added a commit to FrostyX/tito that referenced this issue Dec 28, 2023
FrostyX added a commit to FrostyX/tito that referenced this issue Dec 28, 2023
FrostyX added a commit to FrostyX/tito that referenced this issue Dec 30, 2023
FrostyX added a commit to FrostyX/tito that referenced this issue Dec 30, 2023
@FrostyX FrostyX added effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward labels Jan 1, 2024
@FrostyX FrostyX moved this from In 2 years to Needs triage in CPT Kanban Jan 2, 2024
@FrostyX FrostyX moved this from Needs triage to In Progress in CPT Kanban Jan 2, 2024
@FrostyX FrostyX self-assigned this Jan 2, 2024
FrostyX added a commit to FrostyX/tito that referenced this issue Jan 4, 2024
FrostyX added a commit to FrostyX/tito that referenced this issue Jan 4, 2024
FrostyX added a commit to FrostyX/tito that referenced this issue Jan 4, 2024
FrostyX added a commit to FrostyX/tito that referenced this issue Jan 15, 2024
praiskup pushed a commit that referenced this issue Jan 15, 2024
@praiskup praiskup moved this from In Progress to Done in CPT Kanban Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward RFE This issue is a Request For Enhancement (Feature)
Projects
None yet
3 participants