ci: Test devcontainer image with repos

[lurtz]

I am always afraid that devcontainer internal tests do not catch everything. Thus build the devcontainer locally and test it at multiple repositories, which is quite time consuming.

With these tests it is assured that bazel build and test for selected repos and revisions work and stay working.

[FScholPer]

Nice feature but can you also document that in the readme?!

[AlexanderLanin]

We do the same in docs-as-code. We've decided to call it consumer tests. On every PR we run half a dozen consumers with the PR version. This takes ~10 minutes, but it has saved us sooooooooooooo much trouble.

[AlexanderLanin]

Nice feature but can you also document that in the readme?!

First thought was yeah!!! But on second thought... we never document workflows anywhere. Maybe a comment on top of the yml file?

It would also be a lot more self explanatory with separate workflows?

[lurtz]

We do the same in docs-as-code. We've decided to call it consumer tests. On every PR we run half a dozen consumers with the PR version. This takes ~10 minutes, but it has saved us sooooooooooooo much trouble.

ok, for consistency I will rename it to consumer tests

It would also be a lot more self explanatory with separate workflows?

That will be very tricky, because building a container image takes a lot of time. In the current approach the image is build once, tested and if tests pass, published.

If I want to avoid building the image more than once, I need to save it somehow and share it among workflows. I do not know if that is easily possible.

Nice feature but can you also document that in the readme?!

At some point it may make sense to trim down the README.md and move sections into separate files. I think the label is definitely something needing documentation.

[opajonk]

I like it!

The label stuff not triggering the label event... sounds like a bug. But nothing we can fix.

[lurtz]

I like it!

The label stuff not triggering the label event... sounds like a bug. But nothing we can fix.

In other cases this worked. However there the label was evaluated directly in the jobs if condition. Maybe Github scans for that