On Mon, 3 Oct 2016 15:57:14 -0600 Tim Flink <tflink@xxxxxxxxxx> wrote: > 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". Thanks. > > > 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. Fair enough. I just thought it would be worth mentioning. > 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. Yeah, I don't have much of a horse in this race either. I guess it depends on how much maintainers will find tests being added/edited/etc as noise or not. > > 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. ok. Thats fair. > 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. Excellent. ...snip... kevin
Attachment:
pgpC8kUZOdIhi.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
