[releng-scripts] --device-tags should also request the actual tag in the job

Submitted / merged: https://gerrit.automotivelinux.org/gerrit/c/AGL/releng-scripts/+/21466

OK, we need to talk through that. Yes, I get your point.

The issue with the current approach is:

• let's say we want to do the can tests that we're written. Atm we have no way to know if they're going to be executed or not.

• It all depends on which device we happen to hit by chance.

So yes, we need to tell what tags are required  for the test to run on - upfront.

Let's talk in the next call how we proceed.

For now, we just add the

And be done.

In the "boards available" detection, yes we could wait for tags. But the question is: what tags are we waiting for? And who tells us which tags to wait for? That is the chicken-egg problem.

Right now we probe the tags based on available devices, then generate jobs based on what tags we found.

If we want to select and available board based on tag/tags. Where do those tags come from?

:

wrt (b): no, I did not mean to rethink all.

Looking at https://git.automotivelinux.org/ci-management/tree/jjb/common/include-agl-lava-labs-prepare.sh#n81 , we only report the tags of the found device.

We'd have to check for a match against --device-tags XYZ (there or later) and fall into the wait-loop if not to wait for the device with the tag to free-up. Thoughts ?

Yes, we're in a chicken-egg situation as we're basically re-doing the scheduling of lava - sort-of.

For the individual pipeline we need a little more control over the flow as we want to report back to gerrit / the developers. So we can't just wait for any result to eventually pop-up.

For your (a) above. Agreed. We will add the `tags` section to the job to ensure job runs on device with the detected tags.

For (b) we have a bit of a chicken-and-egg problem.

The way things were designed today is based on picking available boards, not waiting for specific boards. So the "boards available" first checks if there are idle devices available for a given device-type. If available, only then does it query the tags for that available device. Now that we know there is 1) an available device and 2) the tags that device has, we can generate a LAVA job with the right set of tests suitable for that device-type and tag.

Stated differently, we find an available board, and then customize the job/tests for that board.

What you're suggesting, IIUC, is to do the inverse: which is to have a customized job/test (e.g. for a specific tag/feature) and then submit to any boards which match that specific set of tags/features. That makes a lot of sense for interactive use, but I'm not sure if it does for the CI loop where we want to optimize throughput. If we do that, it would mean a rethink/redesign of the current flow.

That being said, I think simply adding the `tags:` section above when using `--device-tags` in releng-scripts should solve the problem for interactive use.