New repo-checker to be deployed on August 14th

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

New repo-checker to be deployed on August 14th

Jimmy Berry-2
packagers,

A complete rewrite of the tool that runs as factory-repo-checker on OBS is
scheduled for deployment on August 14th as the new user repo-checker. This new
tool fixes a number of major shortcomings and bugs with the previous tool that
result in errors detected that were previously not detected. As such simple
version updates may be rejected until these issues are resolved.

Both to provide a grace period and tooling improvement going forward the tool
will now regularly post comments on packages with issues in their corresponding
devel project. The 112 comments went out Wednesday on a variety of packages.

Issues with any ring package will block an entire letter stagings just as a
failing builds have previously. Due to the issues with the previous tool a
number of problems currently exist with ring packages. In order to roll out the
tool I started to fix the problems, but ended up finding too many so a whitelist
will be used and relaxed as issues are fixed. See the Factory config [1]
repo_checker-package-whitelist{,-x86_64,-i586} lines to see which packages are
whitelisted and work to resolve those problems. The complete list of problems
can be found in the repo_checker file [2]. If you help fix ring problems it
is appreciated if you link to the requests in the tracking issue [3] so the
whitelist can be relaxed as they are accepted.

Overall, the new tool is significantly simpler in terms of lines of code, code
complexity, and workflow complexity. Also faster! See the initial rewrite pull
request for more details [4].

Summary of changes/features:

- all architectures are checked (currently i586, x86_64) instead of just x86_64
- requests are checked in staging groups instead of devel projects
  - no more review spam during intermediary stages
  - properly handle ghc-* requests
  - cycle check based on entire group which properly catches problems
  - no longer a requires the latest version from devel
  - expect reviews not to be accepted until the entire group is built and passes
- summary comments on staging projects to notify submitters of problems
- new user repo-checker on requests
- comments on packages in devel projects based on current Factory:standard

The new repo-checker is currently soft-enabled for Factory in that it will be
checking all requests, but only commenting when it sees a problem and having no
effect on reviews. On August 14th all new requests will require approval from
the new repo-checker user on OBS.

An example of problems detected during the soft-enablement that the old repo
checker passed over can be seen currently on Staging:B [5].

For a summary of planned improvements to the tool see the issues on github [5].
Report issues there using the title prefix 'repo_checker: '.

Enjoy!

[1] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashboard/config
[2] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashboard/repo_checker
[3] https://github.com/openSUSE/osc-plugin-factory/issues/1012
[4] https://github.com/openSUSE/osc-plugin-factory/pull/964
[5] https://build.opensuse.org/project/show/openSUSE:Factory:Staging:B
[6] https://github.com/openSUSE/osc-plugin-factory/issues?&q=is%3Aissue%20is%3Aopen%20repo_checker

--
Jimmy
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New repo-checker to be deployed on August 14th

Sebastian-2


On 08/05/2017 03:46 PM, 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.
>
>
> On 08/05/2017 12:34 AM, Jimmy Berry wrote:
>> packagers,
>>
>> A complete rewrite of the tool that runs as factory-repo-checker on OBS is
>> scheduled for deployment on August 14th as the new user repo-checker. This new
>> tool fixes a number of major shortcomings and bugs with the previous tool that
>> result in errors detected that were previously not detected. As such simple
>> version updates may be rejected until these issues are resolved.
>>
>> Both to provide a grace period and tooling improvement going forward the tool
>> will now regularly post comments on packages with issues in their corresponding
>> devel project. The 112 comments went out Wednesday on a variety of packages.
>>
>> Issues with any ring package will block an entire letter stagings just as a
>> failing builds have previously. Due to the issues with the previous tool a
>> number of problems currently exist with ring packages. In order to roll out the
>> tool I started to fix the problems, but ended up finding too many so a whitelist
>> will be used and relaxed as issues are fixed. See the Factory config [1]
>> repo_checker-package-whitelist{,-x86_64,-i586} lines to see which packages are
>> whitelisted and work to resolve those problems. The complete list of problems
>> can be found in the repo_checker file [2]. If you help fix ring problems it
>> is appreciated if you link to the requests in the tracking issue [3] so the
>> whitelist can be relaxed as they are accepted.
>>
>> Overall, the new tool is significantly simpler in terms of lines of code, code
>> complexity, and workflow complexity. Also faster! See the initial rewrite pull
>> request for more details [4].
>>
>> Summary of changes/features:
>>
>> - all architectures are checked (currently i586, x86_64) instead of just x86_64
>> - requests are checked in staging groups instead of devel projects
>>   - no more review spam during intermediary stages
>>   - properly handle ghc-* requests
>>   - cycle check based on entire group which properly catches problems
>>   - no longer a requires the latest version from devel
>>   - expect reviews not to be accepted until the entire group is built and passes
>> - summary comments on staging projects to notify submitters of problems
>> - new user repo-checker on requests
>> - comments on packages in devel projects based on current Factory:standard
>>
>> The new repo-checker is currently soft-enabled for Factory in that it will be
>> checking all requests, but only commenting when it sees a problem and having no
>> effect on reviews. On August 14th all new requests will require approval from
>> the new repo-checker user on OBS.
>>
>> An example of problems detected during the soft-enablement that the old repo
>> checker passed over can be seen currently on Staging:B [5].
>>
>> For a summary of planned improvements to the tool see the issues on github [5].
>> Report issues there using the title prefix 'repo_checker: '.
>>
>> Enjoy!
>>
>> [1] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashboard/config
>> [2] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashboard/repo_checker
>> [3] https://github.com/openSUSE/osc-plugin-factory/issues/1012
>> [4] https://github.com/openSUSE/osc-plugin-factory/pull/964
>> [5] https://build.opensuse.org/project/show/openSUSE:Factory:Staging:B
>> [6] https://github.com/openSUSE/osc-plugin-factory/issues?&q=is%3Aissue%20is%3Aopen%20repo_checker
>>
--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New repo-checker to be deployed on August 14th

Jimmy Berry-2
In reply to this post by Jimmy Berry-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]