-
Notifications
You must be signed in to change notification settings - Fork 49
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
Comments
Absolutely love this!
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. |
friendly ping :) is there any work on this planned in the near future? This'd be very helpful in FCOS and OKD. |
I don't understand this part. Why do we need to send locally built srpms to koji? |
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. |
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. |
This is partially done (upstream triggers) and the downstream trigger is covered by #55. |
I propose to create a new handler, "build":
Counter-proposal to #46
This is coming from https://github.com/packit-service/packit/issues/264
The text was updated successfully, but these errors were encountered: