Using kas in development

[Larson, Chris]

Greetings,

 

I’m attempting to use kas more during development, rather than largely as a tool for quick build testing or as an easier mechanism for users, and am running into certain issues with this use case. Specifically, when I’m making code changes and checking them in, I’m finding that kas is a serious barrier due to its behavior of always checking out the defined revisions from the kas configuration, even if the current HEAD is based on that revision, so I have to remember to go check my branches back out again, and it results in not building the code I was working on.

 

I would like to disable the checkout behavior, or get it set to HEAD for all repositories, when doing active development like this. Obviously I could leave everything not checked in, and the dirty repository state would prevent kas from checking it out, but having to actively avoid making early-and-often commits is troublesome, and manually modifying files to force a dirty state would be a very ugly workaround.

 

Presumably I could attempt to create a .yml which uses override to adjust the revs to HEAD, and provide one of these in each of my layers that provides a kas config, but I’m wondering if there’d be any objection to adding a `--no-checkout` argument for this sort of usage. Any thoughts? Thanks,

--

Christopher Larson

Siemens AG

www.siemens.com

[Jan Kiszka]

Hi Chris,

We likely need to document "--skip repos_checkout" somewhere. --skip is
documented, but I also had to search again how the checkout step is
actually called. Patch welcome.

Some way to list all available steps per plugin would probably make
--skip even more useful - or dangerous, depending on what people will
with that.


That said, I'm also heavily using kas in development, but with different
workflows: If I have to fix or enhance some upstream layer, I develop
the changes in a regular clone first and only import them temporarily
for downstream testing afterwards via the layer patch feature of kas.
This avoids spreading own, possibly valuable commits for upstream repos
across the various throw-away clones that kas creates.

And if I juggle around with upstream layer revisions, I'm doing that by
editing the kas files that define them. But there is now also the
alternative to work with lock files instead, specifically when riding
upstream repo branches (see
https://kas.readthedocs.io/en/latest/userguide.html#dump-plugin). That's
primarily interesting when you have a larger number of layers (more an
OE thing, normally not with isar).

Only during tricky debugging sessions, I may actually touch what kas
just checked out - but then it will stay away from automatic updates anyway.

Jan

--
Siemens AG, Technology
Linux Expert Center

[Larson, Chris]

This is very helpful, thanks, though I've found inconsistency in how this argument is handled and obeyed. The argument is set up with argparse as a string argument with a list default value, and it's assumed to be a list elsewhere, i.e. in the handling of -k in kas shell, so if you pass -k and --skip both to `kas shell`, it'll fail due to an attempt to append to a string as though it was a list. I'm assuming we just need to change the action or set nargs='*' on this to fix that. I'll submit a patch for this if I get the time today.

But beyond that, using "--skip repos_checkout" can fail if any layers use layer patching, since they've already been patched, and repos_apply_patches wasn't skipped. I've run into this before, though I'm not sure why it doesn't consistently notice they've already been applied, it seems to attempt to checkout the base first. Still, it checking things out and applying patches isn't what I want if I'm making changes to the layer, so we might just want to add the -k/--keep-config-unchanged to "kas build" the way it is for "kas shell"? There's no way to pass multiple steps to skip to --skip today, but that should be fixed by adjusting the nargs/action.

> Some way to list all available steps per plugin would probably make --skip even more
> useful - or dangerous, depending on what people will with that.

Agreed, that would be nice, I may prototype something.

> That said, I'm also heavily using kas in development, but with different
> workflows: If I have to fix or enhance some upstream layer, I develop the changes in
> a regular clone first and only import them temporarily for downstream testing
> afterwards via the layer patch feature of kas.
> This avoids spreading own, possibly valuable commits for upstream repos across the
> various throw-away clones that kas creates.
>
> And if I juggle around with upstream layer revisions, I'm doing that by editing the kas
> files that define them. But there is now also the alternative to work with lock files
> instead, specifically when riding upstream repo branches (see

> https://kas.readthedo/
> cs.io%2Fen%2Flatest%2Fuserguide.html%23dump-
> plugin&data=05%7C02%7Cchris.larson%40siemens.com%7C061d4e3ea40a41f06d
> 4708dc59b3d158%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63848
> 3876058347057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CLPs
> JXgraZNwZQbwy8PLgLNWIwubJ0Vv1n23ju%2FUF10%3D&reserved=0). That's

> primarily interesting when you have a larger number of layers (more an OE thing,
> normally not with isar).
>
> Only during tricky debugging sessions, I may actually touch what kas just checked
> out - but then it will stay away from automatic updates anyway.

That's interesting insight into your workflow, thanks for providing it! I'll have to give my own workflow some thought, but it's good to allow for multiple workflows with the tool. Thanks again!

--
Christopher Larson
Siemens AG

http://www.siemens.com/