Repository navigation
Conversation
|
What's the reason for putting each of the individual steps into their own runners though? Shouldn't a single runner be enough for all of them? |
Following Icinga DB and Icinga for K8s.
As stated in the OP, this squashes four diverging approaches into one. |
I did read that but you're squashing them into the wrong approach IMHO. All those steps shouldn't need their own runners each. Yes, they're not long running but still I would just add them as separate steps instead like how IGL and Icinga Notifications already do. |
Add a generic GitHub Actions Workflow to build and test all our Go code. It is based the IGL, Icinga DB, Icinga Notifications, and Icinga for K8s.
|
Changed it and triggered another CI run for all consumers.
Please feel free to tell me directly if you think another approach would be better. This Socratic questioning just introduces a round-trip. |
Hu, did I say something wrong? I didn't check at first what Icinga DB and Kubernetes used to run those steps, so I asked a simple question to get if there's a reason for this that I'm not aware of. Is this socratic questioning? Also, I already commented what I think, is better, directly with my previous comment. |
Sorry, I didn't mean to sound rude. I just wanted to refer to your first (and rightful) comment, where you asked why I did this. |
Add a generic GitHub Actions Workflow to build and test all our Go code. It is based the IGL, Icinga DB, Icinga Notifications, and Icinga for K8s.
At the moment, this will just unify our Go actions. In a later step, a SBOM attestation will be added based on the Go built, including the compiler version and so on. This, however, requires a common GitHub Actions workflow.
The four downstream PRs successfully went through. However, some need a change in the required actions, which changed due to the unification.