Thanks for the review and feedback, Tim. Dominik has already
addressed most of the questions. Adding a couple of thoughts
from my point of view.
On 30 January 2018 at 18:32, Dominik Perpeet <dperpeet(a)redhat.com> wrote:
I will try to address a few of the points.
On 01/30/2018 04:33 PM, Tim Flink wrote:
> How are git repos in different namespaces of a larger repo
> ecosystem easier to link together than just urls that point to
> github or pagure.io ?
> There has been some talk about pulling in tests that live in
> upstream repos which makes me think github. If this is true and
> we're going to be pulling other things in from
> github/pagure/gitlab/wherever, why not just have these shared
> repos in pagure.io?
There is no technical reason currently, other than the
convenience of grouping. One of the possible options with
grouped repos is the ease to add something in the future, such
as modifying access control or even providing optimized Pagure
workflows for common use cases.
Grouping similar content such as tests at the same place rather
than scattering around various locations sounds natural to me.
Having a decent test coverage at one place can serve as a nice
source of examples for inspiration and allows to develop tooling
which can enhance the process. For example, upon detecting test
update execute it against all supported environment combinations.
> Is the Fedora dist-git instance set up to enable ACL lists made
> up of users who are not already packagers and who don't
> otherwise have write access to the corresponding package repo?
> If not, how much extra work are we talking about? Are there
> available cycles to get the work done in short order?
Currently only fedora "packagers" have access to dist-git itself
for actions such as cloning. There is a workaround to open pull
requests from other git repos:
The tests namespace should allow access not only for Fedora
packagers but for anyone willing to contribute. This should also
resolve the problem that many QE guys are not in the packagers
group and thus cannot commit directly. With this approach qe/dev
collaboration on the test coverage should be easier.
> As I understand it, RHEL QE has a setup with a
> namespace which stores all the tests for a package whose name
> matches the name of that repo from the tests namespace. If we
> use "tests" as the namespace here, I fear that we will be
> adding to confusion from the people who are used to the RHEL
> version of a "tests" namespace.
I believe all tests should be linked from the package's dist-git
- wherever that path may lead (in the dist-git itself or another
repo, even upstream).
> We would also not realistically be able to replicate a similar
> setup in Fedora. There seemed to be interest in something like
> that when the issue came up on devel@ a few years ago which
> also makes me think it'd be unwise to close this door unless
> there is no other reasonable choice. If we do go the dist-git
> namespace route, have there been any alternative names
I see your point about possible confusion. On the other hand,
the test namespace basically is an open-source sister of the
internal one: It shares the same motivation, which is to have
shared tests guarding the feature specification hosted outside /
independently of the package dist-git branches.
However, we should not expect that it will be mirrorring exactly
in the same way. There will be differences. IMO it does not make
sense to have a separate git repository created for each and every
package. For example, it makes much more sense to have a single
ruby repository for integration tests of many ruby-* packages.
> - For the PR testing case, how will the shared tests be
> included in that PR set for testing purposes?
All relevant tests should be linked to the repo where they will
gate changes (e.g. changing shell tests will gate on those
passing on bash, ksh, et cetera).
> - Will there be some delay in test/build kickoff on dist-git
> repo change to allow for tests to be pushed around the same
> time that there are code changes? Otherwise are we planning to
> expect some transitory failures if both the tests and packages
> need to change at the same time? Are there plans to verify
> that things are properly re-run if those transitory errors
The best way here is to reference the exact version of the tests
you want, by git repo and revision. Then you don't depend on
chance and you can safely change the tests first, then the
I expect the scenario described above suits more to upstream unit
tests (adding feature with test in one commit). For OS CI I think
we should be more focused on stable features (tests guiding the
specification), basic functionality and integration testing rather
than checking every little feature. Thus I do not expect so many
collisions of this type.
But as Dominik already mentioned, in cases where it makes sense
it's possible to fetch tests from a specific branch or even commit
to prevent unwanted failures. Another way is to only add the new
test to the dist-git tests.yaml file only when it's ready for
testing. Or use an appropriate test metadata to select only
relevant tests from the whole test set.
> The question of how to deal with non-packager write access for
> tests has been brought up a couple of times but I'm not sure
> it's been dealt with well yet.
> I don't really like the idea of tests with arbitrary ACLs. As
> we work toward a vision of having CI gate all changes to
> packages before those changes are even accepted, changes to the
> tests associated with a package start approaching the
> importance of the non-test content for the same package.
> If someone tosses an unproven test into a shared repo before
> going home for the weekend - there is a chance that could cause
> all sorts of problems from keeping a package's changes out of
> stable to breaking the build of a release-blocking image.
The ACL for a test repository should not be arbitrary. By default
I expect package maintainer and qe should be granted write access
but otherwise collaboration on the tests should work in identical
way as with other open-source projects: A new contributor can
start with proposing pull requests and later can be granted write
access when trust is established between them and repo maintainer
after good experience / number of successful merges.
> I realize that there are plans to handle situations like this
> with automatic reversion but to the best of my knowledge, that
> system doesn't exist yet (an admin could back stuff out before
> the automation exists, too). If we demand that packagers go
> through a vetting and mentoring process even if they're a
> co-maintainer, why shouldn't we have a similar requirement for
> the folks who can change the tests which are responsible for
> gating the bits we release?
The starting point of test execution is the dist-git repo
itself, which underlies the known restrictions. It is up to the
packager to decide which other repo to link to, if at all. The
tests could feasibly be in the dist-git repo itself or any other
repo the packager trusts (and that is publicly accessible). If
we should limit that choice somehow, we need to discuss it.
It perfectly makes sense (especially when tests are getting more
importance because of gating) to ensure that anybody who has write
access to the tests repo is aware of all important aspects of the
process. Keeping a good/clear/concise documentation up-to-date
should be one of the essential steps here.
> It makes sense, just some concerns about the specifics of this
> proposal. Thanks for putting so much time into this.
Thank you for a nice bunch of good points! :)