Add option to suppress commit of applied patches

siemens / kas

Setup tool for bitbake based projects

MIT License

353 stars 144 forks source link

Add option to suppress commit of applied patches #57

Closed tewarid closed 3 years ago

tewarid commented 3 years ago

Committing patches creates a commit hash that does not exist in the source repo. Yocto buildhistory reports that hash which results in a loss of traceability. It would be interesting if kas provided an option to suppress commit of applied patches.

jan-kiszka commented 3 years ago

Suppressing alone won't work. We would need an alternative patch management, quilt based or so.

jan-kiszka commented 3 years ago

BTW, does this have more impact than just the initial printout of OE? That alone should not be a major issue, given that the log also contains what kas did right before that.

tewarid commented 3 years ago

buildhistory contains the build-id.txt file of the following kind

Build Configuration:
BB_VERSION           = "1.51.1"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-musleabi"
MACHINE              = "raspberrypi0-wifi"
DISTRO               = "poky"
DISTRO_VERSION       = "3.3+snapshot-4d5f053e38fd951028d5267a295f285425da4c71"
TUNE_FEATURES        = "arm thumb vfp arm1176jzfs callconvention-hard"
TARGET_FPU           = "hard"
meta-berry           = "main:e4c9945e3f899adb61e4978a04525a2f8c78ed7d"
meta-clang           = "master:eb92914e31ff872c032155997c42ca8b6e6d82a3"
meta-matter          = "main:e4c9945e3f899adb61e4978a04525a2f8c78ed7d"
meta-networking      
meta-oe              
meta-python          = "patched-master:04038652399b8e8917687367cacf2477acdafa73"
meta-raspberrypi     = "master:c7f4c739a3762b9a39696898876f242b17df6f59"
meta                 
meta-poky            
meta-yocto-bsp       = "patched-master:4d5f053e38fd951028d5267a295f285425da4c71"

It is easier to parse than the log.

jan-kiszka commented 3 years ago

Understood - but be warned that, when you remove patches from the log, the shown revision of the layer will not be the built revision. That can also be highly misleading!

tewarid commented 3 years ago

Understood - I think I can live with committing the precise refspecs I've built by altering kas config manually.

jan-kiszka commented 3 years ago

I mean, kas patching layers is a hot-fix method, nothing that is supposed to stick (you are supposed to upstream your changes ASAP :wink:). So the ideal build is clean, refspec and, thus, patch-wise.

OTOH, if OE could be told to not only issue refspecs but possibly also git describe outputs, kas could tag the baseline in a way that makes both the base and the modification visible. Maybe this feature can be contributed to OE-core...

tewarid commented 3 years ago

Thanks - I'll close this issue for now.

henning-schild commented 3 years ago

Unlike repo or submodules kas allows to patch locally without a need to fork a "repo", if you can not live with the "random shas" you can still fall back to forking and simply use a fork/branch where your patches are already applied. Doing so should give you stable hashes and you might still see benefits in using kas over other similar tools.

henning-schild commented 3 years ago

But kas itself does know the refspec it applied patches on, and it is becoming increasingly popular in the "OE/yocto" world. So we could in the long run thing about leaving a tag for a baseline. But i am afraid that might be hard considering layering, where a patching kas-yml might be based on another patching kas-yml ... and so on.