Iterations on the Developer Experience for writing specs by solsson · Pull Request #28 · Yolean/kubernetes-assert

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

solsson · 2021-05-11T12:33:42Z

Feature branch goal:

Make specs driven development more attractive than ad-hoc manual testing. If we succeed, backend PRs will include specs that provide knowledge transfer and can be used for automated regression testing.

with builds-registry URLs

so let's look for alternative appoaches, starting with #26

Speed up dev loops that involve the assert runtime

need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Make RBAC resources opt-in for the runtime-nodejs base

solsson · 2021-05-11T13:39:21Z

Next experiment after #26:

Focus on a CI/CD environment where we want the asserted backends to keep running
But the specs should exit 0 after X consecutive passes of all specs
An initial wait of Y seconds before starting specs could be useful to reduce test noise
A configurable interval between reruns would also be useful to reduce noise

Unlike in dev environments where we aim for one-liners, during CI/CD it's trivial to maintain a set of environment variables for the container.

The reason exit is so important is that with the current generation of kubernetes-assert we're having issues with specs that stay around for very long and thus produce lots of test data and other types of noise/costs.

solsson · 2021-05-20T13:27:24Z

From the evaluation internally we've observed that:

It's a clear improvement that specs stop running upon success
- Specs that produce test data no longer fills our database :)
- Logs get easier to follow
Actually it's also common that both dev and CI/CD results in failed specs that keep running, at least until the next working day. There is no improvement for that scenario.
We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls
- But they should have the same so that developers:
  - Get one stream of logs to follow
  - Don't need two terminals
  - Are always encouraged to be test driven during skaffold dev

solsson · 2021-05-20T13:43:29Z

An initial wait of Y seconds before starting specs could be useful to reduce test noise

Relatively low priority.

A configurable interval between reruns would also be useful to reduce noise

Relatively low priority. 10 s is a very good default.

But the specs should exit 0 after X consecutive passes of all specs
... it's also common that both dev and CI/CD results in failed specs that keep running

Can we find criterias and runtime changes so that spec containers always exit?

If all specs have passed X times we exit 0
- Should lead to a Completed status in kubectl get pods.
Evaluate a max time for the specs container, after which it exits non-zero if there are still test failures
- Can this be cobined with restart policy so that the pod doesn't crash loop but instead we get an Error status.
- How do we prevent exit when someone is actually developing?
  - Max time countdown should be reset on actual file watch change
  - We can define "actually developing" as editing the specs at least once within the max time interval.

We tricked ourselves, based on ystack example specs that specs and app should have separate skaffold yamls

The examples we run should dev both backend ans specs in the same skaffold dev command.

If we succeed with the above, the y-assert hack in ystack could be replaced with something that basically does kubectl get pods with some selector on specs' labels and checks the pod status.

Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

This reverts commit 66e447a.

Update jest.kubernetes-assertions-reporter.js

Cladnicand others added 10 commits May 10, 2021 14:38

Update jest.kubernetes-assertions-reporter.js
bdc4838

Update jest.kubernetes-assertions-reporter.js
f5cb1c6

We currently have no use for specs images outside skaffold runs
c97c3bd

For dev loops involving a runtime we need [git rev][-dirty?] tags
136c2bf
with builds-registry URLs

Was misleading to have a dockerfile while relying on y-build-like-sync
6586929

As#19documents this env no longer works
b50c145
so let's look for alternative appoaches, starting with #26

Makes use ofYolean/ystack#39so we can iterate on runtime+specs
abc1f63

Merge pull request#27from Yolean/assert-devloop-improvements-build
990f268
Speed up dev loops that involve the assert runtime

Moves RBAC resources to a dedicated base, so specs that don't
51c5bdb
need rbac can be created and deleted faster. Specs might not use the kubernetes client, or mighte have sufficient access with the default service account such as in ephemeral test clusters.

Merge pull request#29from Yolean/assert-rbac-separate-base
e5d600b
Make RBAC resources opt-in for the runtime-nodejs base

solsson assigned Cladnic and darclander May 11, 2021

solsson added a commit that referenced this pull request May 19, 2021
Merge current#28into experiments-autobuild
ce5fc46

darclanderand others added 3 commits May 24, 2021 23:21

Timeout and delay
66e447a
Timeout and delay should now be implemented for the cluster. Have not had enough time to see if it works properly. The logic should be there though. The image is not exited but there is a condition for where it should.

Revert "Timeout and delay"
fd7189e
This reverts commit 66e447a.

Merge pull request#26from Yolean/avoid-rerunning-passed-specs
73060fa
Update jest.kubernetes-assertions-reporter.js