.github: Add integration tests that installs cilium and queries it using Hubble CLI

[chancez]

I noticed we don't have any tests that actually hit cilium, so this should fix that.

[gandro]

Awesome, thanks a lot for doing this!

[kaworu]

Thanks @chancez !

[chancez]

Hmm I can't see to get hubble to return any flows. I wonder if there's something wrong with relay and hubble in the values I'm using.

[kaworu]

@chancez pushed a few commits on top of yours, tested locally with act -j integration-test and the integration tests succeed on my machine, no idea why it's failing in CI though :sad-parrot:

Also added the needs-rebase label because we will want to squash the commits before merging.

[chancez]

Added more commands to check flows at the post-test info gathering step. It seems if we query hubble status (over port-forward) at the end, the nodes are connected via relay and relay is reporting flows.

If I then query for flows in the agent, it works, but if I query flows over the port-forward, it doesn't.

Collecting hubble status
+ ./hubble status
Healthcheck (via localhost:4245): Ok
Current/Max Flows: 1,593/4,095 (38.90%)
Flows/s: 4.76
Connected Nodes: 1/1
+ kubectl -n kube-system exec ds/cilium -c cilium-agent -- hubble status
Healthcheck (via unix:///var/run/cilium/hubble.sock): Ok
Current/Max Flows: 1,595/4,095 (38.95%)
Flows/s: 4.76
+ echo 'Checking flows 1'
Checking flows 1
+ ./hubble observe -n kube-system -o jsonpb
+ echo 'Checking flows 2'
Checking flows 2
+ kubectl -n kube-system exec ds/cilium -c cilium-agent -- hubble observe -n kube-system -o jsonpb
{"flow": .... .}

It's very strange. I thought it was relay, and it might be, but it's able to report back the status, so I'm not suspicious it's just the port-forward, or Hubble CLI itself.

[chancez]

Interesting.. with debug logs it indicates it's reading from stdin. I wonder if I broke it (again) with #874

258 time="2023-01-27T19:50:25Z" level=debug msg="Reading flows from stdin"

[chancez]

Okay, I took my work-around from timescape and added it. The key is adding this, which makes the commands running in the step think they're running in a TTY, preventing Hubble CLI from incorrectly assuming no-TTY == data being fed in via stdin.

        shell: 'script -q -e -c "bash --noprofile --norc -eo pipefail {0}"'

[chancez]

It's stuck waiting on build, but I think it's because I renamed that action to unit-test instead, in a different PR. If anyone can help fix that in the settings @gandro or @rolinh

[gandro]

It's stuck waiting on build, but I think it's because I renamed that action to unit-test instead, in a different PR. If anyone can help fix that in the settings @gandro or @rolinh

Not sure I follow. The workflow in question is renamed in this PR. We can ignore the required build in this PR for now and an admin can merge it once it's marked ready-to-merge.

But before this PR is merged, I don't think we should change the the required settings, because all other PRs would then be unable pass the requirements (until this one here is merged).

[chancez]

Not sure I follow. The workflow in question is renamed in this PR. We can ignore the required build in this PR for now and an admin can merge it once it's marked ready-to-merge.

Ah you're right, I was juggling two PRs and thought I renamed it in the other PR. That being said, this PR is ready @gandro

[nbusseneau]

LGTM.

[gandro]

Thanks! Updated the required pipelines, all open PRs will have to rebase.