Support wildcards in COPR allowed list #2907

evgeni · 2025-12-15T07:49:03Z

TODO:

Write new tests or update the old ones to cover new functionality.
Update doc-strings where appropriate.
Update or write new documentation in packit/packit.dev.

Fixes #2906

Related to fedora-copr/copr#3804

Merge before/after

RELEASE NOTES BEGIN

Packit now supports wildcards in COPR allow lists

RELEASE NOTES END

gemini-code-assist · 2025-12-15T07:49:17Z

Summary of Changes

Hello @evgeni, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to Packit's COPR integration by allowing the use of wildcards in the allowed list for forge projects. This change provides greater flexibility for users to define broader patterns for permitted projects, simplifying configuration and management, especially for large organizations or projects with consistent naming conventions. The update ensures that the system can now match project names against patterns like git.instance.io/the/example/namespace/* rather than requiring exact matches.

Highlights

Wildcard Support for COPR Allowed Lists: Packit now supports the use of wildcards in the packit_forge_projects_allowed configuration for COPR builds, enabling more flexible project matching.
Implementation of fnmatch: The fnmatch module has been integrated to provide Unix shell-style wildcard matching capabilities for forge project names against the allowed list.
Expanded Test Coverage: New unit tests have been added to validate the correct behavior of wildcard patterns in the COPR allowed list, ensuring the new functionality works as expected.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

Fixes: packit#2906

gemini-code-assist

Code Review

This pull request introduces support for wildcards in the COPR allowed list, which is a great enhancement. The implementation looks correct, and the added tests cover the new functionality well.

I've added a couple of suggestions to improve the robustness of the code by handling cases where the allowed list might be None, and to add a corresponding test case.

Overall, this is a solid contribution.

gemini-code-assist · 2025-12-15T07:50:23Z

packit_service/worker/helpers/build/copr_build.py

        )
        allowed_projects = copr_project["packit_forge_projects_allowed"]
-        allowed = self.forge_project in allowed_projects
+        allowed = any(


The allowed_projects variable could be None if the packit_forge_projects_allowed field is not set in the Copr project settings. This would cause an AttributeError when splitlines() is called. To make this more robust, you can handle the None case.

Suggested change

allowed = any(

allowed = any(fnmatch.fnmatch(self.forge_project, pattern) for pattern in (allowed_projects or "").splitlines())

I don't think the API will ever return None here. And the old code wasn't accounting for that either (in doesn't work on None).

gemini-code-assist · 2025-12-15T07:50:24Z

tests/unit/test_build_helper.py

+        pytest.param(
+            JobConfig(
+                type=JobType.copr_build,
+                trigger=JobConfigTriggerType.pull_request,
+                packages={
+                    "package": CommonPackageConfig(
+                        owner="the-owner",
+                        project="the-project",
+                    ),
+                },
+            ),
+            "something/different\ngit.instance.io/the/example/namespace/*",
+            True,
+            id="wildcard-more-values",
+        ),


To improve test coverage and ensure robustness, please consider adding a test case for when packit_forge_projects_allowed is None. This will verify that the application handles this edge case gracefully without raising an exception.

You could add a parameter like this:

pytest.param( JobConfig( type=JobType.copr_build, trigger=JobConfigTriggerType.pull_request, packages={ "package": CommonPackageConfig( owner="the-owner", project="the-project", ), }, ), None, False, id="none-allowed-list", ),

centosinfra-prod-github-app · 2025-12-15T07:50:36Z

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/efdc5a8efae743c1ae7a093650168304

✔️ packit-service-tests SUCCESS in 19s (non-voting)

centosinfra-prod-github-app · 2025-12-15T07:51:17Z

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/bb01da1c08d84a92956237095f33e8df

✔️ packit-service-tests SUCCESS in 19s (non-voting)

softwarefactory-project-zuul · 2025-12-15T07:53:56Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/254ea655d4ed4f31ad0f58ffcf6b4168

✔️ pre-commit SUCCESS in 1m 46s
✔️ packit-service-tests SUCCESS in 3m 18s

lbarcziova

thanks a lot for the contribution!

lbarcziova · 2025-12-17T10:22:48Z

packit_service/worker/helpers/build/copr_build.py

-        allowed = self.forge_project in allowed_projects
+        allowed = any(
+            fnmatch.fnmatch(self.forge_project, pattern)
+            for pattern in allowed_projects.splitlines()


we are receiving list here, so the splitlines() shouldn't be here:

>>> r = c.project_proxy.get("lbarczio", "test-repo") >>> r["packit_forge_projects_allowed"] "['github.com/the-project/*', 'github./com/the-project/the-namespace']"

I'm afraid it's worse than that…

>>> config = {'copr_url': 'https://copr.fedorainfracloud.org'} >>> c = Client(config=config) >>> r = c.project_proxy.get("lbarczio", "test-repo") >>> type(r["packit_forge_projects_allowed"]) <class 'str'> >>> r["packit_forge_projects_allowed"] "['github.com/the-project/*', 'github./com/the-project/the-namespace']"

It's a string that looks like a list!

(that's with Python 3.13 and copr 2.5 from PyPI, I have not tested any other combos)

https://github.com/search?q=repo%3Afedora-copr%2Fcopr%20packit_forge_projects_allowed&type=code hints it should be whitespace separated (so the splitlines was technically wrong), but I don't understand why we're getting a stringified list here.

ooh, good catch, let me have a better look

so I think the list is created correctly here, but probably when transforming to API response, the string from here is being enforced

if you would like to use this asap, we can work with the stringified list here (ideally fix this later), otherwise we could first fix this on Copr side

there is no rush on my side, let's do it properly!

once fedora-copr/copr#4092 is released, we can proceed here

we had copr release recently so that would take a while... We could do hotfix for this after new year (but there's high chance I'll forget so in that case please ping me :D)

no problem, I think we can wait for the normal release

lbarcziova · 2025-12-17T10:23:50Z

tests/unit/test_build_helper.py

+                    ),
+                },
+            ),
+            "something/different\ngit.instance.io/the/example/namespace/*",


from a quick check I think we have here the test values incorrect as well, all these should be lists, should I have a look or could you cover it here?

I can totally fix these up as I go, but first we need to figure out what the real API response is.

Schema incorrectly defined field as String instead of List(String), causing Flask-RESTX to stringify the list in API responses. Context: packit/packit-service#2907 (comment) Assisted-by: Cursor(Claude)

evgeni requested a review from a team as a code owner December 15, 2025 07:49

usercont-release-bot added this to Packit Kanban Board Dec 15, 2025

github-project-automation bot moved this to new in Packit Kanban Board Dec 15, 2025

Support wildcards in COPR allowed list

52096ba

Fixes: packit#2906

evgeni force-pushed the wildcard branch from f24bff1 to 52096ba Compare December 15, 2025 07:50

gemini-code-assist bot reviewed Dec 15, 2025

View reviewed changes

lbarcziova reviewed Dec 17, 2025

View reviewed changes

lbarcziova moved this from new to in-review in Packit Kanban Board Dec 17, 2025

lbarcziova mentioned this pull request Dec 18, 2025

frontend: fix packit_forge_projects_allowed to return list in API fedora-copr/copr#4092

Merged

nikromen mentioned this pull request Dec 22, 2025

SOP: how to build a hotfix fedora-copr/copr#4056

Draft

	allowed = any(
	allowed = any(fnmatch.fnmatch(self.forge_project, pattern) for pattern in (allowed_projects or "").splitlines())

Support wildcards in COPR allowed list #2907

Are you sure you want to change the base?

Support wildcards in COPR allowed list #2907

Uh oh!

Conversation

evgeni commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot commented Dec 15, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

centosinfra-prod-github-app bot commented Dec 15, 2025

Uh oh!

centosinfra-prod-github-app bot commented Dec 15, 2025

Uh oh!

softwarefactory-project-zuul bot commented Dec 15, 2025

Uh oh!

lbarcziova left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

evgeni commented Dec 15, 2025 •

edited

Loading