Hi Miro, that's a really valid point that we should somehow resolve. Is this always the case with the mass rebuilds that they should be left unbuilt or just with your Python rebuilds?
I am thinking about multiple options here: 1) configurable allow-list / block list for committers (for the user and/or for the whole service) * For our projects, we would allow just the `packit` user that we use for submitting the dist-git pull requests. * We could probably react to just `packit` commits for all the users but I don't like this all-or-nothing approach. (That people are required to use all the Packit's features or none.) 2) check the committer for not being a proven packager (Packit is not a proven packager and we don't want to change that. We would like to have as few permissions as possible.) * I don't see any technical problem with the implementation here and personally see this as a possible solution. 3) use a commit message to skip/trigger the build * We can't inform everyone about this feature so skipping the build by commit command is probably not a good idea. * And forcing the commit structure to trigger the build makes it hard to use. We can probably think about this more, but the second option looks the best for me so far. Automation is not reduced and work for proven packagers is untouched. What do you think? Would this work for you? Or, do you have any better idea/solution? Thanks for bringing this up! František On Fri, May 6, 2022 at 2:19 PM Miro Hrončok <mhron...@redhat.com> wrote: > On 06. 05. 22 11:06, Frantisek Lachman wrote: > > Hello all, > > > > You might have heard some rumours that the Packit team is working on > automation > > for downstream activities you need to do when working on a new release > of a > > package to Fedora. And the rumours are true – I am really pleased to > announce > > that Packit now covers the whole workflow from upstream development to > Bodhi > > update. We try to reduce the human interaction with the system to places > where > > it’s needed and wanted and do all the mundane work and busy waiting for > you. > > > > > > If you want to take a look at how it works, here is a blog post showing > this on > > one of our packages: https://packit.dev/posts/downstream-automation > > <https://packit.dev/posts/downstream-automation> > > > > > > We have used the automation ourselves for a couple of weeks for our > packages[0] > > and already got bored of the releases. It’s too simple. > > > > And if you haven’t heard about Packit at all, check our web page: > > https://packit.dev <https://packit.dev> > > > > > > We know that people can have different needs, so let us know what you > think > > about it. And if you hit any issues or have any suggestions, get in > touch with > > us – ideally, in #packit:fedora.im <http://fedora.im> on Fedora Matrix > or in > > form of an upstream issue created here: > > https://github.com/packit/packit-service/issues/new > > Hey František. > > I read that "If Packit sees a new commit in the configured dist-git > branch, it > submits a new build in Koji like maintainers usually do." > > Does that mean that if a provenpackager (e.g. me) commits to > rpms/python-ogr in > order to rebuild the package in a side tag (e.g. f37-python for Python > 3.11 > rebuild), packit will build it in the regular target, preventing the side > tag > build from happening (the same NVR cannot be built multiple times in Koji)? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
