For option 2, it could feasible to cutdown the cloning time from git push . the process will continue to slowdown the push, but not so much. It's just theory, but it might work: 1. We keep an updated master working copy somewhere else: ci working copy 2. On pre-receive hook, we create a branch on ci working copy, apply the commited patches, run ansible-report . if ansible-report returns 0, we move master to the same ref where the testing branch is, otherwise we checkout master and delete the testing branch That will reduce the testing time since we will not clone the repo on every commit. Anyhow, I feel that we are planning to emulate a CI system that runs tests on a PR and automerge them on success with custom bare git hooks, and this will be a long-term headache to maintain. So, is there any benefit on doing this instead of planning a PR+CI+automerge on success with existing tools? Regards and happy friday for all, On October 25, 2019 3:03:36 PM GMT+02:00, Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: >Hi all, > >Today jlanda, austinpowered and mizdebsk discussed about ticket >https://pagure.io/fedora-infrastructure/issue/8157 in #fedora-admin and >came up with a few questions on how to implement that solution that I >think >would be nice to share with the wider group. > >There are basically 2 possibility : > >1 - We run ansible-report as a pre-commit hook >This means that ansible-report will be run locally before a contributor >commit a change. This is not ideal since our contributor are running >all >kind systems (rhel, fedora, windows ?) so having something that work >well >for everyone will not be simple. Also this forces our contributors to >install ansible-report locally. > >2 - We run ansible-report as a pre-receive hook >This means that ansible-report is run on batcave01, but we cannot run >ansible-report just on a commit, we need to run the tool against the >full >repository every time. That involve making a clone of the repo applying >the >changes in the incoming commit, then run ansible-report on that >repository. > >This has also a few disadvantages, first we first need to clear all the >errors reported by ansible-report in our repo before we enable the hook >otherwise all commits will be rejected. It will also slows down every >pushes (time to clone, apply patch, run the tool). > >Do people have other ideas ? Is this change worth the trouble ? > >Thanks Julen Landa Alustiza <jlanda@xxxxxxxxxxxxxxxxx> _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx