Discover targets when building in users Copr repo

[csomh]

It's pretty cumbersome for users who are using their own Copr repositories to keep the list of chroots in sync with the target lists in the jobs.

This could be improved if the service could be configured to set the targets for jobs based on what chroots are enabled in the user provided Copr repo.

Something like:

jobs:
- job: copr_build
  trigger: release
  owner: "@cockpit"
  project: "cockpit-preview"
  targets: copr_chroots

Or going further: targets could become optional when a user provided Copr repo is used, with the default behaviour to get the list from the Copr repo.

(The example above uses the metadata-less config variant, which is not yet released.)

[csomh]

Is this what you meant, @martinpitt?

[martinpitt]

Or going further: targets could become optional when a user provided Copr repo is used

Right, that would be my intuition. Right now it is required, and thus one needs to keep the copr config and all 5 repos that use it in perfect sync.

I ran into this today in our releases, the first time that packit did these: https://github.com/cockpit-project/cockpit-ostree/runs/6386292898 ("Submit of the build failed: Only owners and admins may update their projects"). Apparently packit tried to reconfigure our copr for the build targets mentioned in packit.yaml, and failed because it is a "builder". It never asked for admin privs, and I wouldn't be that comfortable with handing them out to a bot.

I manually synced the copr's build targets with the list in packit.yaml, and then it worked. My main worry is how to maintain that in the future -- for each new fedora/c9s release we'd need to update all packit.yml files in lockstep and configure the COPR in the same way.

If possible, it'd be much nicer to just drop targets: for a custom COPR, and just let the creator of the COPR maintain the target list there.

Thank you!

[mfocko]

Dropping it with the check for custom repository makes more sense and IMO might be easier to implement

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[mfocko]

Part of this was done in packit/packit#1694. I have a smallish issue with triggering the Copr build via /packit test

[martinpitt]

Yay, thank you so much for fixing that! We use the same copr across all cockpit projects, and making changes to the build targets has been really painful until now (up to the point that we just didn't do it, and shrugged off issue reports). I'll try it soon!

[mfocko]

@martinpitt just an FYI that it will be deployed on production on Tuesday

[martinpitt]

@mfocko:

I wanted to test this today on my forked project. I dropped the copr targets list and added an extra debug commit that diverts the COPR from the official cockpit one to my own one.

However, nothing at all happens with packit -- usually I get some packit job statuses on the tagged release commit, but I only see the upstream release (which worked). At the first attempt I got an automated comment from packit about configuring allowed github repos in COPR, which I did -- both in my martinpitt/test-fixes and the official cockpit one. Then I force-pushed and re-attempted the release, and silence. There was no issue filed, no job started, and https://dashboard.packit.dev/jobs does not have anything about martinpitt/cockpit-ostree either.

Is there some infrastructure outage, or something wrong with my packit.yaml that doesn't get reported anywhere?

Thank you!

[martinpitt]

martinpitt/cockpit-ostree@c348b72 was the last "test release" commit that I did on the same project, 4 months ago. That commit has rpm-build packit statuses. However, these may have been for the propose_downstream job, which I deleted now in my debug commit as this really isn't something for Fedora. So strictly speaking I did not see a copr_build github status back then either. But where are these logged, if not on https://dashboard.packit.dev/jobs ?

[mfocko]

@martinpitt sorry about the trouble, I have a guess it's related to the deployment, I will check and fix it

[mfocko]

@martinpitt it should be fixed already, @majamassarini rebuilt and imported image with the correct version of Packit :)

[martinpitt]

@mfocko : Niiice! I re-did the test release, and this time I see the workflow runs from copr/packit, the packit dashboard page, and the build in my COPR. That has the correct targets, so all is well now. So now, only the documentation needs to be updated.

Yay, now off to cleaning this up for our real projects 🎉

Thanks a lot! This really makes maintenance a lot easier on our side.

[mfocko]

I know about the documentation, Friday work :) :D