---- On Tue, 17 Dec 2024 12:17:30 -0300 Sasha Levin wrote ---
On Tue, Dec 17, 2024 at 03:49:53PM +0100, Greg KH wrote:
On Tue, Dec 17, 2024 at 11:30:19AM -0300, Gustavo Padovan wrote:
---- On Tue, 17 Dec 2024 11:15:58 -0300 Greg KH wrote ---
On Tue, Dec 17, 2024 at 11:08:17AM -0300, Gustavo Padovan wrote:
Hey Greg, Sasha,
We are doing some work to further automate stable-rc testing, triage, validation and reporting of stable-rc branches in the new KernelCI system. As part of that, we want to start relying on the X-KernelTest-* mail header parameters, however there is no parameter with the git commit hash of the brach head.
Today, there is only information about the tree and branch, but no tags or commits. Essentially, we want to parse the email headers and immediately be able to request results from the KernelCI Dashboard API passing the head commit being tested.
Is it possible to add 'X-KernelTest-Commit'?
Not really, no. When I create the -rc branches, I apply them from quilt, push out the -rc branch, and then delete the branch locally, never to be seen again.
That branch is ONLY for systems that can not handle a quilt series, as it gets rebased constantly and nothing there should ever be treated as stable at all.
So my systems don't even have that git id around in order to reference it in an email, sorry. Can't you all handle a quilt series?
We have no support at all for quilt in KernelCI. The system pulls kernel branches frequently from all the configured trees and build and test them, so it does the same for stable-rc.
Let me understand how quilt works before adding a more elaborated answer here as I never used it before.
Ok, in digging, I think I can save off the git id, as I do have it right _before_ I create the email. If you don't do anything with quilt, I can try to add it, but for some reason I thought kernelci was handling quilt trees in the past. Did this change?
What if we provide the SHA1 of the stable-queue commit instead? This will allow us to rebuild the exact tree in question at any point in the future.
Yeah, future-compatibility sounds better. As long as we have a git tree, a SHA1 and can match that to the test execution in KernelCI it works.
Is that SHA1 different from the one in the stable-rc release?