[FEATURE] Add 'baketext' support where appropiate

[oliv3r]

Using variables with kicad is great, we can put in our schematic things such as $COMMENT1 or $GIT_VSC_TAG (which is generated in preflight.

However, these tags are 'replaced' with the actual text in the git repository that holds the kicad files, which is 'logical'. One (complex) way of dealing with this is a pre-commit script that would replace the value when you create a git tag; but if you update the code, you'd have to re-update this tag, becoming quickly cumbersome.

KiKit introduces a nice feature called baketext, that will expand variables when it creates new panel.kicad_pcb.

This is currently not done for other things kibot generates, such as present, navigate or kicanvas. Therefor I recommend that we get a flag (or even do it as default), where variables get expanded in these 'releases'.

Probably worth a different feature request, but we'd also could probably use to generate a simple 'dumb' output, that basically just copies (with baked text) the schematic and pcb files. One thing that's subtle here, other then 'why not just do sed in > outdir/pcb.sch, is that we don't know all files to copy, more specifically, not all schematics (with hierarchical schematics).E.g. when invoking kibot with --schematic root.kicad_sch --board board.kicad_pcb, kibot (kicad) will know exactly which schematic and board files to use, e.g. kicanvas etc all have the correct files included. Thus having a 'copy' output that does all preflight and other processing is definitely useful.

[set-soft]

Please explain it better.

1. The set_text_variables can change the variables in a permanent way, which means storing them in the project. What else do you want?
2. Usually you don't commit SCH/PCB files after running KiBot, so I fail to understand how any change will be permanent.

Please describe an step by step workflow for:

1. The "cumbersome" situation
2. The situation after the feature is implemented

BTW: You can already copy the schematic and or PCB using KiBot.

[oliv3r]

Please explain it better.

1. The _set_text_variables_ can change the variables in a permanent way, which means storing them in the project. What else do you want?

I actually do NOT want to store them in the project; the git repository is to be (at all times obviously) untouched. For the obvious 'dirty-ness' reason, but also we won't commit changes as part of the pipeline anyway.

2. Usually you don't commit SCH/PCB files after running KiBot, so I fail to understand how any change will be permanent.

That's an interesting point; but I also have 'restore' in my config set. So one work-around would indeed be, do not restore the files, but copy them after kibot as an output.

Please describe an step by step workflow for:

1. The "cumbersome" situation

Manually (or using kibot) change the text variables (but also the built-in kicad variables). e.g. whenever $COMMENT1 is used, we'd have to manually change that in the sch/pcb files.

I suppose when manually doing this, one would; parse project file (or root schematic), and then all linked schematics run sed 's|$VAR|content|g' parsedfile.kicad_ > outdir/release.kicad_.

2. The situation after the feature is implemented

We have a job running (build, deploy whatever) which will resolve all variables to static texts, those generated by kibot; but also those generated/populated by kicad. The generated files are now placed as an output into the output folder.

Again, pretty much what is done with kibot present, navigate or kicanvas.

BTW: You can already copy the schematic and or PCB using KiBot. But not using just an output? I'll research this option :)

[set-soft]

I suppose when manually doing this, one would; parse project file (or root schematic), and then all linked schematics run sed 's|$VAR|content|g' parsedfile.kicad_ > outdir/release.kicad_.

But this equivalent to what the (deprecated) sch_replace and pcb_replace preflights do.

I still don't understand why is this needed. You should invest some time in creating a very simple example and KiBot configuration showing the use case and what is the exact problem with what we currently have.

[oliv3r]

So I tried the copy_from; and copy_files needs a list of files, which I don't know, but kibot does.

The simple example my pipeline template in itself. https://gitlab.com/ci-includes/kici. Here, the pipeline runs, and generates all sorts of outputs; see for example the output of the latest tag; https://gitlab.com/ci-includes/kici/-/jobs/7999345181/artifacts/browse where all generated outputs are shown. What's missing however, is the schematics and pcb files, with prefilled variables, because those are in the repository. However when sharing these files (output) you don't get the pcb files or schematics (well you do, because they are part of kicanvas, present or navigate, IF you use those outputs). So having an output that just does the pcb files would be enough to be able to 'release' them and offer them for easy sharing.

Actually kicanvas is more complete then present or navigate, as that also includes the project file. Granted, you do have to explicitly configure kicanvas to do so, so a generic 'kicad' output probably should just do that anyway ...

[set-soft]

So I tried the copy_from; and copy_files needs a list of files, which I don't know, but kibot does.

Look at the ExportProject template.

The simple example my pipeline template in itself. https://gitlab.com/ci-includes/kici.

Nope, this isn't a simple example.

Here, the pipeline runs, and generates all sorts of outputs;

And hence isn't a simple example

see for example the output of the latest tag; https://gitlab.com/ci-includes/kici/-/jobs/7999345181/artifacts/browse where all generated outputs are shown. What's missing however, is the schematics and pcb files, with prefilled variables, because those are in the repository.

The variables are in the project, as long as you copy the project you'll get the values.

However when sharing these files (output) you don't get the pcb files or schematics (well you do, because they are part of kicanvas, present or navigate, IF you use those outputs).

ExportProject is used to share your project.

So having an output that just does the pcb files would be enough to be able to 'release' them and offer them for easy sharing.

Ok, is already implemented, you also sch_variant and pcb_variant. But they are good only if the other person has the 3D models.

Actually kicanvas is more complete then present or navigate,

?!! I can't understand how kicanvas is more complete than navigate, which can include kicanvas

as that also includes the project file.

Like the outputs I mentioned before.

Granted, you do have to explicitly configure kicanvas to do so, so a generic 'kicad' output probably should just do that anyway ...