Github actions

[lachmanfrantisek]

Follow-up to https://github.com/packit/packit/issues/1231#issuecomment-841128159

It would be nice to provide parts of the packit workflow in a form of Github actions.

• It can be a huge benefit:
  • modular/tweakable approach
  • not our infrastructure
  • user's identity instead of ours
  • Implementation does not need to be hard -- just a wrapper around our CLI or Python API.
• The problems:
  • Not relevant for other git forges (like GitLab/Pagure).
  • We probably still want to support regular service (=Github app) => more code to take care of.
  • Not all workflows are so straightforward (e.g. bodhi update that requires changes to be already merged to distgit, see #1231).

As a team, we don't have the capacity to work on this now, but it's not unreal we will have the bandwidth to do so in the future.

Please, put :+1: reaction so we know who is interested in this and let us know if you can help us with that -- we would be really glad and provide help and guidance if you want to start working on it.

---

TODO:

• [ ] https://github.com/packit/actions/issues/9

[webknjaz]

Tip: you may want to check out Composite Actions (https://docs.github.com/en/actions/creating-actions/creating-a-composite-run-steps-action). This way you wouldn't have to stick with docker or JS. But note that this feature is rather half-baked (although, what they have may be enough).

[lachmanfrantisek]

@webknjaz Thanks for the tip.

[ssbarnea]

In fact i would go one step further and say that I would like to be able to be able to integrate packit with a local testing tool, like tox. If I can add a tox -e build-rpms which can use containers to build it would be awesome as we would not have to rely to a specific CI/CD provider.

If that works and is documented, we only need to be able to easily integrate it with whatever service the project is using, not only github actions.

[TomasTomecek]

@ssbarnea it would be awesome if you could provide a bit more details for the workflow so we can understand the request right.

you should be able to run packit CLI in a container environment (even in github actions to be honest) - the main downside authentication is if you want to interact with remote service such as copr, src.fedoraproject.org, fedora koji, etc.

[mfocko]

@ssbarnea try to have a look at https://quay.io/packit/packit, if you have containers available I believe it could be bent to your needs ;)

I've just tried it, it was enough to copy the files to the container, switch directory and run packit local-build :)

[ssbarnea]

Installing packit itself is very simple with plenty of options. I am more interested about the list of system containers that are used to test the building, especially the ones mapping to the list of targets from https://packit.dev/docs/configuration/#available-copr-build-targets -- if we would know where to pull the same containers from we should be able to achieve the same functionality using GHA (or other systems).

One particular advantage of using GHA is that it would allow us to chain build operations, for example calling packit pipeline(s) only after another pipeline passed. It makes no sense to test packaging when other checks failed, is only a waste of resources and time, as the final result will likely be reported later. Also cluttering the list of run checks makes it harder to identify the one that failed, for example I expect that all packit checks to fail if user made a change that fails to even produce a python sdist/wheel.

For the moment I plan to use packit as a service, especially as I need to build more experience but this ticket should prove useful to gather feedback from others and see how we diversify the service.

IMHO, the only blocker for creating DIY packit GHA is where should be documenting where the system containers are supposed to be pulled from. Publishing them to multiple registries is very simple and we likely do not want to encourage users to use ones from more or less random sources, as they could easily become outdated or contain customizations that may not give a reliable result.

[TomasTomecek]

Installing packit itself is very simple with plenty of options. I am more interested about the list of system containers that are used to test the building, especially the ones mapping to the list of targets from https://packit.dev/docs/configuration/#available-copr-build-targets -- if we would know where to pull the same containers from we should be able to achieve the same functionality using GHA (or other systems).

It's no longer that easy, especially if you need binary builds for different architectures than x86_64. The problem is that many of such base container images don't have additional repos set up which means that e.g. doing enterprise linux builds is not trivial. I believe this is one of the advantages of packit-service that all of this is taken care of you.

The way this works right now in packit is that builds are happening on live target systems (in copr: VMs or bare metal) while tests happen on freshly provisioned VMs.

One particular advantage of using GHA is that it would allow us to chain build operations, for example calling packit pipeline(s) only after another pipeline passed. It makes no sense to test packaging when other checks failed, is only a waste of resources and time, as the final result will likely be reported later. Also cluttering the list of run checks makes it harder to identify the one that failed, for example I expect that all packit checks to fail if user made a change that fails to even produce a python sdist/wheel.

This is interesting because packit does not submit tests or even builds if sdists (actually SRPM) cannot be created. Can you point us to the actual issue you experienced please?

[TomasTomecek]

The GitHub action for creating SRPMs was created: https://github.com/packit/actions

Still needs tweaking

[ssbarnea]

@TomasTomecek An example on how to use it would be very useful, the repo does not even have a README.md file. I am quite interested in using a github action.

[majamassarini]

On our 2023/Q1 meeting we stated that this epic can be useful for any project that at the moment is not able to accomplish some action as use packit with more complicated workflows, e.g. regarding secrets.

[lachmanfrantisek]

After a team discussion, we didn't pick this as a top Packit team priority for the next quarter and preferred epics with bigger user benefits. (Sadly, we have limited resources...) If anyone wants to help us with this, we will be really glad. We are open to any collaboration and have already successfully implemented/started multiple affords thanks to people outside of the Packit team.