-
Notifications
You must be signed in to change notification settings - Fork 0
Try to use packit to generate copr builds #309
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
Comments
Note information about the upload-artifact action: https://docs.github.com/en/actions/guides/storing-workflow-data-as-artifacts. |
We think that a nightly task that generated an rpm as an artifact could then be run on copr, and that would test our packaging well. |
The next step is to pull the spec file from the Fedora rawhide branch; then update it so it bumps the release, then build the rpm. Is there a tool to bump the release version in a spec file? |
rpmdev-bumpspec |
Blocked by #339 |
We can possibly consider using packit. |
We should try at least doing copr builds, nightly, via GitHub Actions. |
Hi @mulkieran, Packit lead here! Let me know if you need any help with the setup. If you are interested in Copr builds and running tests on top of it, then Packit is most probably the right tool for that. We are more than happy to help you set everything up. (It's usually a few lines of the config file.) The easiest way to contact us is on our team channel The following guide should help you with the basic onboarding: https://packit.dev/docs/guide/ |
I think we have succeeded. |
This is a little challenging compared to some other moves we've done in the recent past. But it makes sense to think of the blackbox tests as really two tasks: building the rpm and then unpacking the rpm and actually running the tests.
Does it make sense to build the rpm as part of a nightly GitHub Action? Can we then post it in a well-known location so another task can use it? Building as part of a GitHub Action seems eminently possible, posting requires permissions.
Running the tests is a different question. The tests try to mimic exactly behavior on an installed system, and that includes starting and stopping the individual tests via systemd. systemd is not available on the docker containers that we have been accustomed to use but is supported via Podman and there is some Podman support in GitHub Actions now: actions/runner-images#320. So running the tests might be possible, so long as the container could be persuaded to present enough storage devices.
The text was updated successfully, but these errors were encountered: