#2624 Proposal: Ban bots from submitting non-scratch koji builds
Closed: Accepted 2 years ago by zbyszek. Opened 2 years ago by decathorpe.

The worst offender here is rhcontainerbot. It regularly submits broken packages, pre-release snapshots without FESCo approval, or packages with wrong version numbers to rawhide as official builds.

Rawhide is not a CI environment, and bots should not be allowed to just auto-submit snapshots builds unattended.

(ELN builds can be exempted from this, obviously, as they only resubmit existing builds for a different buildroot.)


Let's discuss this on devel first? I know this was already linked from Fedora rawhide compose report: 20210619.n.0 changes​, but maybe start a new thread for exposure?

Hi, I own rhcontainerbot. Sorry for the issues on rawhide. I have disabled all autobuilds. Let me check with the containers team and address the concerns on the thread on devel@ . I should have a response by tomorrow hopefully.

I think we should either close this, or repurpose for discussion of policy about requirements for bots. FWIW, I'm against any outright ban on bots, but I think it'd be good to clarify expectations for bot owners.

At the very least, it should be publicly documented who is responsible for active bots, and who is supposed to monitor email notifications (from bodhi, etc.) for that account.

For example, did the bodhi email for rhcontainerbot just go to /dev/null? Otherwise it's hard for me to imagine how so many bodhi update issues were ignored.

At the very least, it should be publicly documented who is responsible for active bots, and who is supposed to monitor email notifications (from bodhi, etc.) for that account.

Last time I checked FAS, I wasn't able to add any reference to myself or any human in the bot account info. I did mention in a few packages above the %changelog line that people check with me if anything. But evidently, I missed a few packages

For example, did the bodhi email for rhcontainerbot just go to /dev/null? Otherwise it's hard for me to imagine how so many bodhi update issues were ignored.

Effectlively yes. We won't be able to monitor all builds everyday, so I'm gonna switch to COPR or OBS or any place that can afford to be broken.

Either way, we'll fix any broken updates in bodhi asap, and will only release RCs and release tags going forward.

Apologies once again.

So, perhaps we should look at something like:

  • non human accounts need to have an associated account system group with responsible humans, named $botname-managers
  • if issues are noted with a bot account, you can always directly contact the human(s) responsible by mailing botname-managers-members@fedoraproject.org
  • If problems are not addressed in a timely manner, file a fesco ticket.

This way bot groups can manage who is resposible (by adding/removing them from the group), everyone knows how to contact the bot admins and there's a way to escalate if problems aren't solved?

That makes sense to me.

nirik's proposal sounds like a good idea, and would be better than an outright ban.

I would be OK with nirik's proposal, but I think it may be a bit too technical. I think just documenting who are the people responsible is enough. This would have the advantage that we could also put a description of the bot itself in the same place. With just a group we have a way to mail some people, but no additional information.

Counterproposal:
- bot accounts have to be clearly identifiable ("bot" substring in the User field, "Bot" substring in the Name field
- a wiki page must be created like for any other user (User:<botname>) where a list of responsible humans is listed.
- a description of what the bot does and why must also be included there

(The wiki page was suggested in the fedora-devel discussion, irc, but I can't find the reference now.)

The wiki page was suggested in the fedora-devel discussion, irc, but I can't find the reference now.

It was actually on the FESCo IRC meeting.

Thats perfectly fine with me too...

Let's discuss this at the next meeting. It might be easier to hammer out some draft interactively.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

2 years ago

Let's discuss this at the next meeting. It might be easier to hammer out some draft interactively.

This is being discussed in the IRC meeting thats going on right now

@kevin: proposal: Bot accounts are allowed, but MUST create a wiki page
with contact information for the human(s) running the bot and
what it does. If the bot causes immediate problems, ask releng
to disable it. If longer term problems, bring to fesco like for
any maintainer.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2QFZBVWSOC7ALCVLOY425UMKLVRRGKXW/

AGREED: Bot accounts are allowed, but MUST create a wiki page with
contact information for the human(s) running the bot and what it
does. If the bot causes immediate problems, ask releng to disable
it. If longer term problems, bring to fesco like for any maintainer.
(+5, 0, -1)

Metadata Update from @churchyard:
- Issue untagged with: meeting
- Issue tagged with: document it

2 years ago

I'd like to resume my beloved rhcontainerbot. This time I'm only gonna use it for koji builds of RCs and release tags. No builds of the latest commits, no bodhi updates whatsoever.

Created a wiki page for it: https://fedoraproject.org/wiki/User:Rhcontainerbot . Please let me know if this is good to go.

Thanks,

@lsm5 I don't fully understand. I assume this bot will submit builds for RC and stable versions to rawhide? But then bodhi updates for those builds will be created automatically for you. Is that what you mean by "no bodhi updates whatsoever"? Or do you mean that bodhi updates and gating status will be monitored by a human?

@decathorpe

  1. rawhide: auto bodhi updates yes, but only for RCs and release tags, not latest upstream commits like before, should be much easier to manage. Humans will look at it :)

  2. fedora releases: fully manual bodhi updates

Does that help?

Alternatively, it would be nice to have a --no-bodhi option in fedpkg build for rawhide builds. That way we can manually submit bodhi even for rawhide.

Alternatively, it would be nice to have a --no-bodhi option in fedpkg build for rawhide builds. That way we can manually submit bodhi even for rawhide.

fedpkg build --skip-tag should do. Than you can tag to the appropriate tag (I guess f35-updates-candidate) to trigger the automatic bodhi update.

Alternatively, you can follow the policy for Updating inter-dependent packages, except you only build one package in the side tag.

fedpkg build --skip-tag should do. Than you can tag to the appropriate tag (I guess f35-updates-candidate) to trigger the automatic bodhi update.

Alternatively, you can follow the policy for Updating inter-dependent packages, except you only build one package in the side tag.

@churchyard cool, thanks for those. I think for now, we'll do automatic rawhide bodhi updates. Given that we'll only do RCs and release tags, the number of updates should be way lower than before. The QE engineer in the containers team as well as myself should be able to handle those. If that becomes a problem we can go with either of the 2 approaches you mentioned.

Does that work for everyone?

Yeah, that sounds good to me. I was just confused by "no bodhi updates whatsoever" in your first comment, this sounds like a good way forward, for now. Thanks!

Yeah, that sounds good to me. I was just confused by "no bodhi updates whatsoever" in your first comment, this sounds like a good way forward, for now. Thanks!

thanks, bot wiki page updated as well https://fedoraproject.org/wiki/User:Rhcontainerbot

@lsm5 I wonder how this one happened?

It looks like you fixed something after the erroneous commit, but the koji build is still tagged, the bodhi update is stable, and the build reached a F35 / Branched compose, resulting in a package downgrade from catatonit-0.1.5-5.fc35 -> catatonit-0.1.5-1.fc35.

@lsm5 I wonder how this one happened?

The autobuild macros i use in the spec file were busted in that package.

It looks like you fixed something after the erroneous commit, but the koji build is still tagged, the bodhi update is stable, and the build reached a F35 / Branched compose, resulting in a package downgrade from catatonit-0.1.5-5.fc35 -> catatonit-0.1.5-1.fc35.

Do I need to bump the epoch or something? Or will it get fixed in the next compose?

It looks like you only built the commit that fixes the upgrade path for rawhide, but not for F35.
https://src.fedoraproject.org/rpms/catatonit/c/85602b65f5a5ce25373290b628c35ae3c138a251?branch=rawhide

Merging this to the f35 branch and building for F35 as well should fix the downgrade issue.

Metadata Update from @zbyszek:
- Issue assigned to zbyszek

2 years ago

Metadata Update from @zbyszek:
- Issue untagged with: document it
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata