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

build trigger 2.0 #47

Closed
1 of 3 tasks
TomasTomecek opened this issue Jul 15, 2019 · 7 comments
Closed
1 of 3 tasks

build trigger 2.0 #47

TomasTomecek opened this issue Jul 15, 2019 · 7 comments
Labels
complexity/epic Lost of work ahead, planning/design required. kind/feature New feature or a request for enhancement.

Comments

@TomasTomecek
Copy link
Member

TomasTomecek commented Jul 15, 2019

I propose to create a new handler, "build":

  • trigger is: dist-git push, upstream PR (NOT upstream release), upstream push
  • it defaults to "copr" but can be overridden to "koji"
  • copr chroots and koji targets can be specified

Counter-proposal to #46

This is coming from https://github.com/packit-service/packit/issues/264

@TomasTomecek TomasTomecek added kind/feature New feature or a request for enhancement. complexity/epic Lost of work ahead, planning/design required. needs-design labels Jul 15, 2019
@LorbusChris
Copy link
Contributor

Absolutely love this!

NOT upstream release

Shouldn't an upstream release be able to trigger a new build as well? (e.g. for projects that don't want/need a new koji build on each push, but for each new tagged release)

@TomasTomecek
Copy link
Member Author

Shouldn't an upstream release be able to trigger a new build as well? (e.g. for projects that don't want/need a new koji build on each push, but for each new tagged release)

Yes, absolutely makes sense, my point here is that I didn't want to make this too big.

@LorbusChris
Copy link
Contributor

friendly ping :) is there any work on this planned in the near future? This'd be very helpful in FCOS and OKD.

@LorbusChris
Copy link
Contributor

LorbusChris commented Sep 10, 2019

local SRPMs can be sent to koji as well
this is a big security concern
if srpm==True, target can't be r"f\d\d" or rawhide

I don't understand this part. Why do we need to send locally built srpms to koji?

@LorbusChris
Copy link
Contributor

I would limit Koji builds to the master branch (or a number of explicitly declared branches on the main repo), and run PRs on COPR.

@TomasTomecek
Copy link
Member Author

TomasTomecek commented Sep 12, 2019

local SRPMs can be sent to koji as well
this is a big security concern
if srpm==True, target can't be r"f\d\d" or rawhide

I don't understand this part. Why do we need to send locally built srpms to koji?

Depends on what you want to achieve. If you want to bypass dist-git: create SRPMs from upstream and send them directly to koji, that's a security concern. If everything goes through dist-git, we should be fine since things can be easily audited. Actually I'm going to remove that part from the OP.

Sadly this is no longer a priority for us: or at least partly.

On the other hand, packit-service already supports pushing stuff to dist-git (which will be able to be triggered by a comment soon #126 ), so the build part will arrive sooner or later.

@lachmanfrantisek
Copy link
Member

This is partially done (upstream triggers) and the downstream trigger is covered by #55.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity/epic Lost of work ahead, planning/design required. kind/feature New feature or a request for enhancement.
Projects
None yet
Development

No branches or pull requests

3 participants