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.

Sign up for GitHub

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

Jump to bottom

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

Closed
4 tasks
TomasTomecek opened this issue Feb 5, 2019 · 26 comments · Fixed by #1278
Closed
4 tasks

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

TomasTomecek opened this issue Feb 5, 2019 · 26 comments · Fixed by #1278
Assignees
@lachmanfrantisek
Labels
complexity/epic Lost of work ahead, planning/design required. downstream kind/feature New feature or a request for enhancement.

Comments

@TomasTomecek
Copy link
Member

TomasTomecek commented Feb 5, 2019 •
edited by lachmanfrantisek
Loading

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
Copy link

hroncok commented Apr 26, 2019

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

@TomasTomecek TomasTomecek transferred this issue from packit/packit Jul 19, 2019
@lachmanfrantisek
Copy link
Member

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

@TomasTomecek TomasTomecek changed the title configuration: figure out auto_build support building in koji Aug 16, 2019
@TomasTomecek TomasTomecek changed the title support building in koji support building in koji in propose_downstream Aug 16, 2019
@TomasTomecek
Copy link
Member Author

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

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

This comment has been minimized.

Sign in to view
@stale stale bot added the stale Is the issue still valid? label Nov 11, 2019
@TomasTomecek

This comment has been minimized.

Sign in to view
@stale stale bot removed the stale Is the issue still valid? label Nov 11, 2019
@stale

This comment has been minimized.

Sign in to view
@stale stale bot added the stale Is the issue still valid? label Jan 10, 2020
@lachmanfrantisek

This comment has been minimized.

Sign in to view
@stale stale bot removed the stale Is the issue still valid? label Jan 10, 2020
@stale
Copy link

stale bot commented Mar 10, 2020

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.)

@stale stale bot added the stale Is the issue still valid? label Mar 10, 2020
@TomasTomecek
Copy link
Member Author

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

@stale stale bot removed the stale Is the issue still valid? label Mar 11, 2020
@lachmanfrantisek lachmanfrantisek self-assigned this Mar 11, 2020
@stale

This comment has been minimized.

Sign in to view
@stale stale bot added the stale Is the issue still valid? label May 10, 2020
@lachmanfrantisek
Copy link
Member

@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?

@stale stale bot removed the stale Is the issue still valid? label May 11, 2020
@TomasTomecek
Copy link
Member Author

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

@stale

This comment has been minimized.

Sign in to view
@stale stale bot added the stale Is the issue still valid? label Sep 5, 2020
@lachmanfrantisek lachmanfrantisek removed the stale Is the issue still valid? label Sep 7, 2020
@lachmanfrantisek lachmanfrantisek removed their assignment Sep 7, 2020
@TomasTomecek
Copy link
Member Author

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.

@stale

This comment has been minimized.

Sign in to view
@stale stale bot added the stale Is the issue still valid? label Jun 3, 2021
@lachmanfrantisek
Copy link
Member

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.)

@stale stale bot removed the stale Is the issue still valid? label Jun 4, 2021
@lachmanfrantisek lachmanfrantisek added downstream complexity/epic Lost of work ahead, planning/design required. and removed triaged labels Jul 8, 2021
This was referenced Jul 8, 2021
Closed
Closed
@praiskup
Copy link

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
Copy link

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
Copy link
Member

@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
Copy link

praiskup commented Sep 2, 2021

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

@lachmanfrantisek lachmanfrantisek mentioned this issue Sep 7, 2021
Closed
7 tasks
@csomh
Copy link
Contributor

csomh commented Oct 6, 2021

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
Copy link
Member

lachmanfrantisek commented Oct 12, 2021 •
edited
Loading

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.)

@lachmanfrantisek lachmanfrantisek changed the title support building in koji in propose_downstream support building in koji for new dist-git commits Nov 1, 2021
@mfocko mfocko assigned mfocko and lachmanfrantisek and unassigned mfocko Nov 1, 2021
This was referenced Nov 11, 2021
Merged
Merged
softwarefactory-project-zuul bot added a commit to packit/packit that referenced this issue Nov 24, 2021
@softwarefactory-project-zuul
Merge pull request #1415 from lachmanfrantisek/config-updates-for-dow…
76ee2d0 
…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>
softwarefactory-project-zuul bot added a commit that referenced this issue Nov 26, 2021
@softwarefactory-project-zuul
Merge pull request #1278 from lachmanfrantisek/downstream-koji-build
d59f9be 
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>
@lachmanfrantisek lachmanfrantisek mentioned this issue Dec 2, 2021
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lachmanfrantisek lachmanfrantisek

Labels
complexity/epic Lost of work ahead, planning/design required. downstream kind/feature New feature or a request for enhancement.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Downstream koji build lachmanfrantisek/packit-service
7 participants
@TomasTomecek @hroncok @praiskup @mfocko @csomh @lachmanfrantisek @rpitonak