Closed VJftw closed 3 years ago
Happy to take a look at this if no-one else is picking this up.
Guessing we want something like:
RELEASE_NOTES.md
generation tool (first slice can pretty much just be the table above, maybe with driver ver added as well)RELEASE_NOTES.md
to determine if probes are already compiled/released so we can avoid recompiling them (reading from the release notes in the checked-out source code rather than from the API)RELEASE_NOTES.md
generation tool after every job).Yes, please! I hadn't put much thought into it, but what you've suggested sounds 💯 . I'm beginning to lean a bit more towards the full generation way to start with in order to reduce our requests to the GitHub APIs as we're hitting limits at the moment (1000/hour).
Our initial implementation of checking if a kernel probe is already uploaded is performed quite late in the build process as we have to obtain the
KernelPackage
including its sources in order to get the kernel probe name. This doesn't really save us much time and means our builds are still quite resource intensive and long as they download aKernelPackage
's sources each time.operatingsystem.OperatingSystem.GetKernelPackageNames()
) we can verify if a given KernelPackage name is already uploaded to the repository. In order to do this, we could store a mapping ofKernel Package Name -> Kernel Probe name
in the release notes. e.g.We could then use this mapping in our tooling to verify if we already have a Release asset of Probe for the given Kernel Package.