openSUSE / scm-staging

Library & tools for staging pull requests from gitea in the Open Build Service
GNU General Public License v2.0
1 stars 6 forks source link

factory-auto erroneously accepts mismatching / rejects matching develprj #52

Open jengelh opened 1 month ago

jengelh commented 1 month ago

Consider https://build.opensuse.org/request/show/1189095 .

The obs source repo is: devel:Factory:git-workflow:staging:ddiss:bcachefs-tools:2 The git source repo is: ddiss/bcachefs-tools

factory-auto should reject it the same way it did to 1189033, because

jengelh commented 1 month ago

On the other hand, if the develprj "chain of custody" is followed, factory-auto erroneously rejects the submission. Consider this:

osc rq list openSUSE:Factory/glslang
1189186  State:review     By:src-o-org-forwarder When:2024-07-23T06:55:09
        Created by: src-o-org-forwarder
        submit:          devel:Factory:git-workflow:staging:jengelh:glslang:1/glslang@1bc7fdc16721be202d9816c2490ee642 -> openSUSE:Factory
        Review by User       is new:       licensedigger                                     
        Review by User       is new:       factory-auto                                      
        Review by Group      is new:       factory-staging                                   
        Descr: glslang 14.3    (🤖: Submission of glslang via
               https://src.opensuse.org/pool/glslang/pulls/1 by jengelh)

The Git PR is from jengelh/glslang to pool/glslang:factory (which maps to openSUSE:Factory/glslang). The develprj of openSUSE:Factory/glslang is X11:Wayland/glslang, which is equivalent to the state in jengelh/glslang. Therefore, the Git PR is in line with "all submissions must come from the develprj".

factory-auto erroneously rejected the corresponding OBS SR. (Yes, I recognize it came from devel:Factory:git-workflow:staging:jengelh:glslang:1/glslang, but its state is also the same as X11:Wayland/glslang. And 1189095 was greenlit too.)

It feels like the develprj check in factory-auto is inverted.

AdamMajer commented 2 weeks ago

I agree, the workflow is inverted. I think there were ideas to remove devel projects.

Personally, I would like to keep devel projects as-is. If we have a devel project and the devel project is either git or the package is in , and the head of OBS devel project match the HEAD of the PR, then bot can do a regular osc sr from devel project. Upon acceptance, merge to factory branch same sources. Nothing else is needed.

I'll add the logic above for devel projects with .