Setup prow CI

[ffromani]

GH actions CI is fine as complement, but our main CI should run in prow, like any other kubernetes or kubernetes-sigs component.

[AutuSnow]

To be honest, I feel we need Prow testing. There are many strange issues in the current code, and even data race issues have emerged. We urgently need to establish a complete CI testing

[ffromani]

To be honest, I feel we need Prow testing. There are many strange issues in the current code, and even data race issues have emerged. We urgently need to establish a complete CI testing

Currently our e2e test (which can be extended) and the unit test all run on github actions. I'm all for expanding coverage and I also think that using prow/kube infra for this form of testing is better, but we have coverage running

[AutuSnow]

Just now, two issues occurred in my testing environment

1. fix(AddResourceClaimAllocation): AddResourceClaimAllocation repeated calls  #88
2. NRI restarts the loop and calls klog.Fatalf when the context is canceled #89 (I'm still modifying the code, and I only raised the issue to track it)
3. I remember that some maps in deviceNameToCPUID do not implement read and write locks, which is also the reason for the data race I mentioned above

[ffromani]

this means we need better testing indeed :) so we will increase coverage and setup prow in parallel with the release process. We can cut a 0.1.1 release once we figure out the process

[AutuSnow]

Did we change the next version to 0.1.1? Isn't it supposed to be 0.2.0?

[ffromani]

Did we change the next version to 0.1.1? Isn't it supposed to be 0.2.0?

we are working to release 0.1.0 to get the ball rolling. The next feature-driven release would be 0.2.0 but if there are urgent or important fixes we can totally cut patch releases

[AutuSnow]

I understand. Thank you for your explanation. Now the project is moving towards a better approach

[ffromani]

I think that with kubernetes/test-infra#36776 we can call this done. Please reopen if I missed something.