feat: add action for assisting with badge verification and migrate to nginx

[corang]

• move badge logic to uds task
  • conditional logic based on github ci or not
• change example package to nginx
  • all 3 flavors
  • behind authservice or sso?
• extend badge logic to work for multi ns/package crd
• Summary at end of badge script
• More validations:
  • package version matches app version in each flavor
• group sections for gh actions (headers?)
• better kubectl-validate pathing for binary

[andrewg-xyz]

Two overall suggestions

1. change everything to "warning" right now. There are assumptions made that may not be accurate.
2. shift logic to tasks.yaml - "builders" should be able to verify all of this easily prior to CI checkout.

Testing out with warnings on packages is a great start, but we should be wary of complication. Should some things shift to elsewhere in the stack? (like netpols from pepr for example or /healthz, ready endpoints)

[daveworth]

I wanted to publicly add that I love this work @corang - it's exactly the direction and shape of work I was hoping to see in Marketplace and it happened with exactly zero nudging from me. ❤️ 🦄

[corang]

Two overall suggestions

1. change everything to "warning" right now. There are assumptions made that may not be accurate.

2. shift logic to tasks.yaml - "builders" should be able to verify all of this easily prior to CI checkout.

Testing out with warnings on packages is a great start, but we should be wary of complication. Should some things shift to elsewhere in the stack? (like netpols from pepr for example or /healthz, ready endpoints)

1. I left some things as warning but the action will never "fail" due to continue on error
2. I'd like to do this eventually but while actively figuring out what logic goes in here I'm going to keep it as an action only

[andrewg-xyz]

Two overall suggestions

1. change everything to "warning" right now. There are assumptions made that may not be accurate.

2. shift logic to tasks.yaml - "builders" should be able to verify all of this easily prior to CI checkout.

Testing out with warnings on packages is a great start, but we should be wary of complication. Should some things shift to elsewhere in the stack? (like netpols from pepr for example or /healthz, ready endpoints)

1. I left some things as warning but the action will never "fail" due to continue on error
2. I'd like to do this eventually but while actively figuring out what logic goes in here I'm going to keep it as an action only

@corang Isn't it easier to test as tasks you can run locally vs github actions? Copy on long-term desire. Keep in mind the in-portability aspect of doing this in github actions? What if a vendor is integrating and they dont' use github for example?

[corang]

Added a new issue #220

[Racer159]

lgtm with those two tech debt issues