backports test automation

backports test automation

[Johannes Berg]

Hi all,

Yesterday Luca and I thought a bit about test automation ... I haven't
really come up with the best thing so far, but here's what I'm thinking
now...

First of all, I think we're currently stretched enough that we have to
restrict ourselves to Linux mainline - we don't have resources to worry
about linux-next, and in particular linux-next could break every day
anyway due to rebases etc. so things there aren't very clear.

Another thing I should say is that I'm trying to avoid having automation
that manipulates the git tree (even adding tags) since we have no
permission model for that and kernel.org trees are supposed to be
controlled by people, afaict.


With that in mind, I think I'd like to have the following:

 * A file in the tree, that indicates the "usable kernel version".
   Currently, that would be 4.19-rc5. This lets us have *some*
   resemblance of tracking what we're doing ...

 * A script that runs every once a while (ok, this is deliberately
   vague), checking compilation against all linux.git tags that are
   newer or equal to the one in the file.
   Typically the nicest thing to do here would be to store the result in
   git notes, but like I said above, I don't want any automation to have
   (full) access to the tree, and I don't think kernel.org can split the
   permissions.
   Thus, I think this should do two things:
    - store the results locally, maybe sqlite or so, to avoid doing
      duplicate work
    - send out the results to the list, with links to logs (or
      attached? better for archiving, but could be big though)

We were also thinking about having tags, but given the git permissions
thing we can't create those automatically ... I suppose somebody could
add them after the emails?

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: backports test automation

[Johannes Berg]

On Tue, 2018-09-25 at 15:10 +0200, Johannes Berg wrote:
> 
> Another thing I should say is that I'm trying to avoid having automation
> that manipulates the git tree (even adding tags) since we have no
> permission model for that and kernel.org trees are supposed to be
> controlled by people, afaict.

Konstantin informed me that he *does* have a way to do per-ref
permissions, so it sounds like in theory we could add a notes ref for
some automation to write test things etc. to. I don't think gitolite
supports a permission check for "just a tag", so I think that's still
out.

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in