On 10/17/2016 06:46 AM, Tim Flink 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.
Several folks have brought up concerns (off list) about our plan to use
sub-directories inside the rpms/ dist-git repos instead of separate
namespaces. The possibility of using namespaces (which are effectively
separate git repositories) did come up but I want to make sure this
discussion topic comes up in a more obvious fashion.
As I understand it, the primary concern is around having non-rpm stuff
in the repo and the commit history. I'm aware of two reasons for that
concern:
- Red Hat uses separate repos internally to hold tests for RHEL
packages and putting checks/tests into the rpm repo will make it
more painful farther down the road for RHEL package maintainers.
I'd like to describe Red Hat's dist-git structure/design. There are two
relevant namespaces:
- rpms/* for regular repositories used for building rpms
- tests/* for storing tests
rpms repositories have product branches similarly to Fedora's dist-git.
Whereas tests repositories have only master branch. There is no global
policy how tests repositories are structured and what goes in.
Everything is on QA group who manages set of repositories.
From workflow point of view:
- for every rpms/ repository there is tests/ repository created
automatically.
- if there are any special operations done on rpms/ repository tests/
repository is also considered here. E.g. removal, deprecation, etc.
- rhpkg (preferred tool for working with dist-git repos - corresponds
with fedpkg) has separate command to checkout tests - "rhpkg tests".
This would roughly correspond to "fedpkg co tests/foo".
Side note about the tooling:
- dist-git repository management on server side started with the same
code base. So as long as Fedora doesn't diverge too much (e.g. pagure
isn't considered internally yet) porting these changes can be fairly
trivial.
- rhpkg, similarly to fedpkg gets majority of the code from pyrpkg
library. If it turns out tests/ support makes a sense in other client
tools pyrpkg may get this code thus get this feature easily. (I'm CCing
cqi who is working on rhpkg/rpkg/fedpkg code and may provide more
insight here).
- Adding the checks/tests into the same repo increases the size of
the repo and could end up requiring more effort to search through
those commits for a specific change
- If there are other concerns, feel free to bring them up.
We chose the directory-in-dist-git option because it seems like the
better, more simple option. It requires fewer steps to get checks/tests
pushed, no extra tooling modification, makes the checks/tests easier to
find and would make for a less complex system overall.
That being said, I don't maintain many packages and I'm not going to
pretend that I know what's best for maintainers. So long as the end
system is consistent, easy to use, makes sense and is feasible to
complete with resources we have, I don't have a strong opinion on
whether we use directories or namespaces to hold checks/tests.
Which brings me to the question that I'd like to get some feedback
on: would it be preferable to store checks/tests within directories of
existing dist-git repos or create a new namespace to store checks/tests
and fiddle around with tooling etc. to hide some of the complexity that
may bring?
I'm wondering if you can estimate what amount of the work is needed here
which excuses mixing up content in the design.
--
Pavol Babincak
Release Engineering, Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
