Mailinglist Archive: opensuse-packaging (127 mails)

< Previous Next >
Re: [opensuse-packaging] New repo-checker to be deployed on August 14th
  • From: Jimmy Berry <jberry@xxxxxxxx>
  • Date: Sat, 05 Aug 2017 22:11:17 -0500
  • Message-id: <4294391.Jarh4b8k6H@boomba.local>
On Saturday, August 5, 2017 8:46:56 AM CDT Sebastian wrote:
Hi,

Is there a possibility to run this bot / these checks locally or on
other projects? I think this would be very useful. Currently it is
necessary to (re-submit to the devel project and then to)[1] re-submit
to Factory to see if the cryptic error messages are gone.

Sebastian

[1]: When someone is not a maintainer. This first usually takes some weeks.


Running the tool on devel projects to provide early feedback is something I
have considered, but would likely require a bit of work to make it work and
not be annoying. Devel projects can see a lot of change while reworking things
that is not as clear to see the final state as SRs grouped together in a
single staging. Additionally, it likely makes sense to filter checks for
packages not submitted to Factory within a devel project, but perhaps also
have a way to enable them.

Alternatively, all of this could also be run manually if the tool was capable
of such operation. It likely is not too far from this, but would require a bit
of logic tweaking to properly overlay the devel repository on top of the
target project to be checked.

The previous checker had quite a bit of logic for trying to figure out which
repositories in a devel project were built against the target project (ex
Factory). I believe it can be done more simply or at worse-case manually
indicated.

The overall workflow is a bit unclear since there is no staging process for
devel projects. As such the rpms from a home:* project problem would need to
be analyzed which could provide false negatives or even positives depending on
what else is built in that project.

Sometimes packages from different devel projects are submitted together to
form a valid update which would of course be seen as broken in devel projects.

Checking individual devel packages overlayed on Factory seems the most
straight forward, but of course that only works if no other packages in the
devel project are needed as dependencies.

Overall, it is a bit mirky how exactly to make this work in devel projects.
Either a project level check or request workflow both have sticky areas. Given
the staging-bot I introduced ensures packages are staged quickly it should not
take too long for them to finish building and the repo-checker to provide
feedback (especially for non-ring packages).

The underlying tools can be run manually, but setting up the appropriate
environment is not entirely trivial (entire copy of Factory and devel project
rpms is required). If interested the primary tools are:

- installcheck from libsolv-tools
- findfileconflicts [1]

And of course the repo_checker.py itself [2] along with repo_checker.pl [3]
that prepares the data to be consumed by the installcheck.

If you would really just like to see what the tool would spit out for a
specific devel project you can manually tweak the code as I have done during
testing. [not on a device that I can easily produce a proper diff]

Use a submit request from Factory just to make the wheels turn. Change line
104 to set the group to your devel project.

group = 'some:devel:project'

Comment out 111 (ie status = api.project_status(group, True)) through 121.

Be sure your devel project uses 'standard' as repo (or change the references
with a conditional based on project). Run with --dry to ensure it does not try
to post a comment.

./repo_checker --dry --debug id 514741

Hopefully, I remembered the rough gist.

[1] https://github.com/openSUSE/osc-plugin-factory/blob/master/
findfileconflicts
[2] https://github.com/openSUSE/osc-plugin-factory/blob/master/repo_checker.py
[3] https://github.com/openSUSE/osc-plugin-factory/blob/master/repo_checker.pl

--
Jimmy
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
References