[FEATURE] Start documenting the various warning/error codes

[oliv3r]

Many linters, such as shellcheck or markdown for example, have extensive documentation on the various error codes. Searching for these codes helps one understand and fix problems.

For example https://github.com/koalaman/shellcheck/wiki/SC2250 or https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md001---heading-levels-should-only-increment-by-one-level-at-a-time

With KiBot, it becomes quite hard to figure what an error code means and how to potentially resolve it.

[oliv3r]

As an example, I just ran my pipeline, and bumped into

WARNING:(W102) Missing footprint information for Q200 (kibot - bom.py:336)

But I have no idea what's missing. ERC and DRC say everything is fine, 3D rendering works.

Looking at the PCB properties:

I'm not seeing anything that's missing or is different from other parts.

Similarly, I don't see anything wrong in the schematic.

So having some documentation on how to resolve this, would be quite useful!

[set-soft]

So having some documentation on how to resolve this, would be quite useful!

I agree, but having this is really hard.
Are you providing the PCB to KiBot?
I'm adding a check for this to the warning now.

IMHO warnings should be self explanatory, so the best is to refine the message.

[oliv3r]

I think it could be as simple as having a wiki page (here on gh) with the page-title/filename of the warning, with a kibot specific prefix (maybe we should do that generally anyway, e.g. instead of W102, KIB102 (KB is knowledge base often) KBOT102 also works? :p

While filling these pages is the really really hard part, making a start is useful. Something like defining a (simple) markdown template, git pull wiki; for i in $(seq 000 120); do cp 'template.md' "KBOT${i}"; done; git add; git push. Then we can (slowly :p) start populating the wiki. This would already help greatly for SOE/discoverability.

As for the self-explanatory messages, I wholeheartedly agree of course. While I had some warnings that reported things with empty quotes, making it even harder to figure out; something like 'got x, expected y ... I don't know.

As for my actual problem, https://gitlab.com/olliver/esptron/-/jobs/8645487143 is my pipeline job that failed, and no, I am not supplying the PCB file, only the root schematic, the PCB file is 'auto discovered' and this works fine for all other jobs, just export is failing.

[set-soft]

I think it could be as simple as having a wiki page (here on gh) with the page-title/filename of the warning, with a kibot specific prefix (maybe we should do that generally anyway, e.g. instead of W102, KIB102 (KB is knowledge base often) KBOT102 also works? :p

I don't like the idea of changing warning codes.

While filling these pages is the really really hard part, making a start is useful. Something like defining a (simple) markdown template, git pull wiki; for i in $(seq 000 120); do cp 'template.md' "KBOT${i}"; done; git add; git push. Then we can (slowly :p) start populating the wiki. This would already help greatly for SOE/discoverability.

Who will populate it? Having 171 templates won't help.

As for the self-explanatory messages, I wholeheartedly agree of course. While I had some warnings that reported things with empty quotes, making it even harder to figure out; something like 'got x, expected y ... I don't know.

Just report it, but with an example.

As for my actual problem, https://gitlab.com/olliver/esptron/-/jobs/8645487143 is my pipeline job that failed, and no, I am not supplying the PCB file, only the root schematic, the PCB file is 'auto discovered' and this works fine for all other jobs, just export is failing.

Auto discovered should be ok. You should try to isolate the issue, I visited your link and it goes to a repo with no files and a protected branch. If you provide a simple test case (PCB + SCH + standalone KiBot config) I can take a look at the reason and add a better description. In fact you should try the current dev code, which should inform if the PCB file name is missing.

[oliv3r]

I think it could be as simple as having a wiki page (here on gh) with the page-title/filename of the warning, with a kibot specific prefix (maybe we should do that generally anyway, e.g. instead of W102, KIB102 (KB is knowledge base often) KBOT102 also works? :p

I don't like the idea of changing warning codes.

Me neither, but 'W102' becomes impossible to google; KIBOT W102 could be a solution. I'm only thinking of the search ability right now.

While filling these pages is the really really hard part, making a start is useful. Something like defining a (simple) markdown template, git pull wiki; for i in $(seq 000 120); do cp 'template.md' "KBOT${i}"; done; git add; git push. Then we can (slowly :p) start populating the wiki. This would already help greatly for SOE/discoverability.

Who will populate it? Having 171 templates won't help.

True, they'd be only placeholders and help with the google index. Populating would still be manual of course; And since it'd be the wiki, editing would be much more trivial. Having nothing will make it harder to discover (where should I put this) and will not add it to any index.

As for the self-explanatory messages, I wholeheartedly agree of course. While I had some warnings that reported things with empty quotes, making it even harder to figure out; something like 'got x, expected y ... I don't know.

Just report it, but with an example.

The idea of course is to reduce the number of reports, when people can self diagnose and repair the issue of course :)

As for my actual problem, https://gitlab.com/olliver/esptron/-/jobs/8645487143 is my pipeline job that failed, and no, I am not supplying the PCB file, only the root schematic, the PCB file is 'auto discovered' and this works fine for all other jobs, just export is failing.

Auto discovered should be ok. You should try to isolate the issue, I visited your link and it goes to a repo with no files and a protected branch. If you provide a simple test case (PCB + SCH + standalone KiBot config) I can take a look at the reason and add a better description. In fact you should try the current dev code, which should inform if the PCB file name is missing.

The link is the pipeline job, which ran for the merge-request !1 which has the files on its own branch. Sorry for not mentioning that.

Meanwhile, I'll try the dev branch. But creating a simple example might be harder, when I don't know what the problem really is of course.

[set-soft]

But creating a simple example might be harder, when I don't know what the problem really is of course.

I found the source of the issue, no need to create a test case. But is simple: Q200 is 2 transistors with 1 footprint.
A patch to support repeated components on panels (ecff968) is producing some interference here

[oliv3r]

Nice!! Ill try out the dev branch!

[set-soft]

Nice!! Ill try out the dev branch!

Note that the dev images were updated a few minutes ago.