On Mon, 3 Oct 2016 15:57:14 -0600
Tim Flink <tflink(a)redhat.com> 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