On Mon, 3 Oct 2016 14:35:00 -0600 Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Mon, 3 Oct 2016 13:50:33 -0600 > Tim Flink <tflink@xxxxxxxxxx> wrote: > > > One of the features for Taskotron that we've been planning since the > > beginning was a way for contributors to maintain their own automated > > tasks/tests which would be run during a package's lifecycle. > > > > I'm happy to say that we're almost to this milestone and wanted to > > get some feedback from devel@ on the specifics of what we're > > planning WRT where these automated tasks will be stored and the > > execution modes that we're planning to support. Our current plan is > > written up at: > > > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/ > > > > The hope is that by making it easier for contributors to write > > automated tasks and making the model completely self-service and > > convention drive, there will be a lot more automated checks for > > packages than we currently have for Fedora. > > > > Please read through the wiki page I mentioned above and give us > > feedback on whether what we're planning to implement is going to be > > useful or if there are areas of the plan which could be improved. > > To clarify at the top you have "Seeing as dist-git will be moving to > pagure before long", the plan there is not to move dist-git, but to > add a partial pagure instance in front of it. This would have issues, > permissions, docs, etc all disabled and would basically just be a way > to add a PR workflow. The existing dist-git setup would be still there > exactly the same. Thanks for the clarification - the emphasis was on coming support for PRs. I've reworded that part of the proposal to make it more clear that dist-git isn't "moving to pagure". > Another alternate here is that we could make taskotron a 'namespace' > like currently rpms/ and docker/ are. Then we would have > perhaps: /taskotron/rpms/foobar/ as the top level and all the rest is > the same. This would get us a seperate pkgdb entry for the taskotron > part of things (ie, it could have different maintainers, people > allowed to commit, etc). That would add to complexity however. That is an alternative that we had been looking at before we learned that dist-git would be getting pull requests. The namespace we were talking about was 'checks/rpms/foobar' which would also open the door for things like 'checks/docker/foobar' or any other type of deliverable which uses dist-git. Our thought is that keeping all the checks in the same repo that spec files live in is going to be easier to use than having to worry about keeping 2 repos in sync with eachother. That being said, we're fine with either storage paradigm and it doesn't matter much if we look for tasks in a directory inside dist-git branches or a separate repo which only holds tasks as long as there is a single convention that is easy for most contributors and doesn't involve something that's unmanageable for the Taskotron devs/admins. > Is there any provision for tests that should be run on _all_ > packages? or we would need to link the test into all repos, etc? > I have in mind a test that would get the checksum from the sources > file and see if it could compare it to upstream. At this point, that's pretty much "come talk to us and we'll get something figured out". I suspect that things which run on all builds/uploads are going to be the minority of tasks that people want to run and for now, it's treated as a special case. So, if you have ideas for checks that would run on all packages or on groups of packages, please come find us. If I'm wrong and there are a lot of more general checks that people want to run, we can speed up plans to make them less of a special case. > Finally, are the lifecycle points triggered via fedmsg? If so, it > would be nice to have a UPLOAD lifecycle where someone has uploaded a > source to lookaside cache. (The above test would probibly be better > at upload time than sources git commit time, but either could work). Everything that runs in Taskotron is triggered via fedmsg so we can add pretty much anything which emits a fedmsg. In this context, there are only so many things which make sense to have in dist-git but that doesn't mean it can't be run. I've started an explicit list of the lifecycle points that we'll be supporting for the tasks stored in dist-git. https://phab.qadevel.cloud.fedoraproject.org/T721 > Thanks for working on all this. It's awesome to see it start to come > to fruition! This has been a wishlist item for as long as I can remember. It'll be great to start new kinds of automation and help make Fedora better :) Tim
Attachment:
pgpEHfUQcGTtH.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
