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

Previously built Copr PR packages used for buildroot initialization #2432

Open
jan-kolarik opened this issue May 23, 2024 · 4 comments
Open
Assignees
Labels
area/copr Related to the integration with copr.fedorainfracloud.org/ complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/low This issue impacts only a few users. kind/feature New feature or a request for enhancement.

Comments

@jan-kolarik
Copy link

In dnf5, we use Packit to run CI tests on pull requests in GitHub.

Once the dnf5 package is successfully built, it becomes part of the Copr repository associated with the GitHub pull request. Any subsequent changes to the pull request retrigger the CI tests and the RPM package build in the same Copr repository containing previously built packages.

Since dnf5 is used to build packages, including itself, it is installed during buildroot initialization using the previously built version from the Copr repository. If this version has a runtime issue, it can affect the buildability of subsequent packages in the pull request.

The only workaround is to create a new pull request, which generates a new Copr repository.

@hroncok
Copy link

hroncok commented May 30, 2024

Copr chroots can be configured to use mock bootstrap images. That should prevent this issue.

@lachmanfrantisek
Copy link
Member

Thanks @hroncok for suggesting this! Looks like this is also configurable via API. This would be really handy!

In the meantime, I've discussed this with the Copr team and they've suggested taking a look at "Copr project directories" (~subproject). It's not documented much and could change a bit but still worth considering -- the directories should not influence each other.

@lachmanfrantisek lachmanfrantisek added kind/feature New feature or a request for enhancement. complexity/single-task Regular task, should be done within days. impact/low This issue impacts only a few users. gain/high This brings a lot of value to (not strictly a lot of) users. labels Jun 3, 2024
@hroncok
Copy link

hroncok commented Jun 4, 2024

Indeed, we use directories regurarly and they don't influence each other (nor do builds from within a directory influence other builds from the same directory).

@jamacku
Copy link

jamacku commented Jun 19, 2024

We have hit the same issue in chkconfig/alternatives:

The initial PR caused alternatives to segfault. Alternatives are in minimal buildroot so any follow-up commits ended with the Packit copr build failing.

We went the same route as @jan-kolarik, and Packit passed since it installed the package from Fedora instead of from copr.

But for some reason, it also rewrote the status checks on the original PR. 😕 So PR 128 has status checks from PR 132.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/copr Related to the integration with copr.fedorainfracloud.org/ complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/low This issue impacts only a few users. kind/feature New feature or a request for enhancement.
Projects
Status: priority-backlog
Development

No branches or pull requests

5 participants