support building in koji for new dist-git commits #55

TomasTomecek · 2019-02-05T10:07:45Z

Support koji builds for new dist-git commits.

Verify, that we accept new events for dist-git commits.
Implement the handler (decide with the team):
- Either enhance the KojiBuildHandler to differentiate between upstream and downstream git forge and act differently.
- Or, create a new handler and new job type.

Edit: complete rewrite v2 by @lachmanfrantisek

hroncok · 2019-04-26T00:04:42Z

one possible configuration might also be: build what bumps release and/or adds changelog.

lachmanfrantisek · 2019-08-15T11:58:57Z

@TomasTomecek can you elaborate on this one? The team is confused. (Is this still needed/wanted?)

TomasTomecek · 2019-08-16T07:15:55Z

@lachmanfrantisek good point, I actually didn't remember what this really was; updated and scoped it down as much as possible

stale · 2020-03-10T15:23:50Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.
We are doing this to be sure that the issue is still relevant. Anyone can comment to remove the stale state. (The issues marked with pinned, security, bug or EPIC label
are not considered stale.)

TomasTomecek · 2020-03-11T08:19:22Z

@lachmanfrantisek this is pretty much your task in this sprint, right?

lachmanfrantisek · 2020-05-11T05:59:12Z

@TomasTomecek I saw koji build and agreed, but this is about propose-downstream, isn't it? I implemented only upstream triggers -- PR, branch-push and release.

When is this expected to run? When the downstream PR is created?
Do we want to inform the user in upstream or downstream?

TomasTomecek · 2020-07-07T12:58:04Z

Good points, we'd need to spend some time on designing this. Ideally we'd just build on dist-git pushes and inform people in the upstream if something goes wrong

TomasTomecek · 2021-03-24T09:06:47Z

Yes, we just need to figure out a mechanism for people to configure downstream jobs in the upstream - having .packit.yaml in dist-git was a dead-end from my PoV.

lachmanfrantisek · 2021-06-04T16:13:00Z

Thinking about this, the workflow used in upstream sends the SRPM directly to Koji so it's not what we want here.

We should:

Verify, that we accept new events for dist-git commits.
Implement the handler:
- Either enhance the KojiBuildHandler to differentiate between upstream and downstream git forge and act differently.
- Or, create a new handler and new job type. (A bit confusing for users but cleaner from the code perspective I think.)

praiskup · 2021-08-30T13:16:21Z

I interpreted this RFE incorrectly before :-( ... so lemme dump a wish here (as I believe it would be for free, if this RFE #55 was implemented)...

Even when Packit upstream workflow is not in use -- it would be nice if we (maintainers) could just manually push to dist-git, and the build was automatically submitted into Koji (submit can be done by any service, but if Packit did this, I'm +1). Configuration like this would be enough.

auto-koji-build-upon-push: [praiskup, ...]

It would be a pity if we bound this cool thing only to upstream-packit workflows, and to the propose_downstream.
I feel a slight mismatch here... meh, so in case this is inapropriate request - perhaps we should consider if we shouldn't implement something like this elsewhere...

praiskup · 2021-08-30T13:20:31Z

auto-koji-build-upon-push: [praiskup, ...]

I mean, I don't want to break releng's scripts, etc. - so perhaps we shouldn't trigger builds for everybody without asking ... therefore the configured list of push event "authors"...

lachmanfrantisek · 2021-08-31T14:32:13Z

@praiskup You are right, the term propose-downstream is here a bit misleading. The task (as I understand it) is to react to a new dist-git commit and submit a koji build for that commit.

The (only) question here is, how this can be configured/enabled (can be combined):

Packit config in downstream.
Hardcoded in the service.
Dashboard or some web-UI to enable this.
Some comment/issue we can react on and automatically save this value to the database.
... anything else?

praiskup · 2021-09-02T10:05:37Z

Anything works for me (if that matters) but if the config lived in dist-git, that would be super trivial to setup IMO.

csomh · 2021-10-06T10:29:48Z

I'm wondering if it would make sense for this and #74 to be two bots, separate from packit-service. I have the feeling we could reach a wider audience this way. For one, we wouldn't need to explain the relationship with packit-service. From a design POV: these bots would operate purely in the Fedora echo-system, and wouldn't need access to anything GitHub.

Or at least: decouple the configuration for auto-building and auto-update-creation from packit configs. Again: the reason for this being to reach a wider audience.

lachmanfrantisek · 2021-10-12T13:17:32Z

We should have a card to discuss/write-down our plans for downstream so just a few notes for the assigned person to cover more points of view on this:

Configuration / how to enable this (packit config x separate service to turn this on x ...)
Code (inside packit and reuse all the listeners and scheduling x do a separate service from scratch)
Packit's instance (reuse the one(s) we have x separate)
Fedora identity in downstream (do we need/want to ask for a new one?)

Regarding the wider audience, do you think creating a new service can bring a wider audience? (We already promised our plans for this on behalf of Packit that finally is somehow known.)

After some thinking about this, I like the idea of decoupling the configuration and adding the functionality as new handlers. Or start with packit config, implement the functionality, test it with packit configs in downstream and do the separate (proper) way of turning this on afterwards. (To have smaller chunks of work and some MVP sooner.)

…nstream-koji-build Add downstream Koji build as new type This is the easiest solution how to do this. See packit/research#123 for more information. Related to packit/packit-service#55 Merge before TBD N/A (will be mentioned in service) Reviewed-by: Tomas Tomecek <tomas@tomecek.net>

Downstream koji build Do not work with fedmsg topics in handlers. The PROCESSED_FEDMSG_TOPICS wasn't used anywhere and @add_topic is not needed because of it. Implement the downstream Koji build. Using a new koji_build job type. Make the SyncFromDownstream react to a general event: Removing of DistGitCommitEvent that filtered the events based on the service config. Events should be independent of handlers and multiple handlers can react to one event. Logic (checking the service config) should be in a handler. Removing FedmsgHandler because it had no function. TODO: feedback and error handling: Commit comment in case of an error on submission; once submitted, users will get a standard notification. tests Fixes #55 Merge after: packit/packit#1415 (required for tests to succeed) When reviewing, please, go commit by commit. There were some class removals/renames that make the whole diff a bit messy. You can set up a new koji_build job using the commit trigger to submit a Koji build for a new commit in a dist-git branch. The configuration file needs to be present in the dist-git for now (the state for the new commit is used). Reviewed-by: Tomas Tomecek <tomas@tomecek.net> Reviewed-by: None <None>

TomasTomecek transferred this issue from packit/packit Jul 19, 2019

TomasTomecek changed the title ~~configuration: figure out auto_build~~ support building in koji Aug 16, 2019

TomasTomecek changed the title ~~support building in koji~~ support building in koji in propose_downstream Aug 16, 2019

TomasTomecek added the kind/feature New feature or a request for enhancement. label Aug 16, 2019

rpitonak added the triaged This issue was already processed by the team. label Sep 12, 2019