search

RedHatInsights / yggdrasil

GNU General Public License v3.0
21 stars 37 forks source link

Use .copr/Makefile for COPR and Packit builds #201

Closed jirihnidek closed 6 months ago

jirihnidek commented 8 months ago
jirihnidek commented 8 months ago

/packit build

subpop commented 7 months ago

Don't packit and COPR provide similar services? Why don't we just use one instead of both?

jirihnidek commented 7 months ago

Don't packit and COPR provide similar services? Why don't we just use one instead of both?

Very good question. I don't know. I would like to use only one service.

subpop commented 7 months ago

@ptoscano , #189 added support for Packit. Do Packit and COPR provide similar services? Can we drop COPR now that RPMs are built by Packit?

ptoscano commented 7 months ago

Packit uses Copr, it is not a full replacement to it.

Copr is a service to provide a personal repository with packages, built according to certain rules, triggers, etc.

Packit is an helper automation for Copr, testing-farm, koji, bodhi, etc. In our case, we use the following setup:

Can we drop COPR now that RPMs are built by Packit?

Not sure why.

subpop commented 7 months ago

Packit uses Copr, it is not a full replacement to it.

Copr is a service to provide a personal repository with packages, built according to certain rules, triggers, etc.

Packit is an helper automation for Copr, testing-farm, koji, bodhi, etc. In our case, we use the following setup:

  • the @yggdrasil/latest Copr has the latest versions of e.g. yggdrasil (this repository), built every time new commits are pushed
  • Packit is used to build the packages of a PR (i.e. including the changes) every time a PR is created/updated; the result of this build is a temporary Copr (not @yggdrasil/latest) that can be used to manually install the packages locally "as repository", and it will be disposed automatically after 60 days (IIRC)

Can we drop COPR now that RPMs are built by Packit?

Not sure why.

As I understand it, the output from both services is functionally identical. The objective of having a build service is to provide installable binary RPMs. Packit does this already, so what is the advantage of building RPMs again in a second COPR project?

ptoscano commented 7 months ago

As I understand it, the output from both services is functionally identical. The objective of having a build service is to provide installable binary RPMs. Packit does this already, so what is the advantage of building RPMs again in a second COPR project?

The builds in Copr are not driven by Packit (they could be, as it is possible to setup a build job on push), and rather built automatically by Copr on git pushes. Those built are kept there indefinitely [1] in the Copr.

Packit is not a build service, but instruments/drives a build service (Copr). The output of the Copr builds driven by Packit are temporary Copr that live the up to 60 days since the last push in a PR: this makes it possible to test a PR by using its binary artifacts directly as repository. Those artifacts are still ephemeral, and kept living only for the purpose of testing a PR. While you could do builds of PRs directly in an existing Copr, this is generally not done as it would fill the Copr with builds that are not integrated yet, and thus appear as "upgrades" to the users of the Copr.

[1] or more precisely, until a certain buildroot/target is still available in the Fedora Copr; the Fedora 39 builds currently done will disappear, together with the rest of the Fedors 39 material, once that release is EOL

subpop commented 7 months ago

As I understand it, the output from both services is functionally identical. The objective of having a build service is to provide installable binary RPMs. Packit does this already, so what is the advantage of building RPMs again in a second COPR project?

The builds in Copr are not driven by Packit (they could be, as it is possible to setup a build job on push), and rather built automatically by Copr on git pushes. Those built are kept there indefinitely [1] in the Copr.

Packit is not a build service, but instruments/drives a build service (Copr). The output of the Copr builds driven by Packit are temporary Copr that live the up to 60 days since the last push in a PR: this makes it possible to test a PR by using its binary artifacts directly as repository. Those artifacts are still ephemeral, and kept living only for the purpose of testing a PR. While you could do builds of PRs directly in an existing Copr, this is generally not done as it would fill the Copr with builds that are not integrated yet, and thus appear as "upgrades" to the users of the Copr.

[1] or more precisely, until a certain buildroot/target is still available in the Fedora Copr; the Fedora 39 builds currently done will disappear, together with the rest of the Fedors 39 material, once that release is EOL

Ok, so then is there a need to having two systems building RPMs? It seems like it would make more sense to use Packit to build both temporary RPMs from PRs, and permanent RPMs from pushes to main. Then we can eliminate the duplication of build instructions entirely.

However, is there a purpose to having RPMs built from main at all? Who uses them and for what purpose?

subpop commented 7 months ago

Since I couldn't express my thoughts in words, I think I was able to more concisely express them in a PR. I would rather we drop the .copr/Makefile entirely and build all RPMs through Packit. This has the neat side effect of using the packit CLI tool to build SRPMs, and build RPMs ad-hoc in either COPR or Koji. #217 is the result.

jirihnidek commented 6 months ago

Closing this PR due to #217