fix: some krw fixes for component onboarding

[scoheb]

Describe your changes

• reconfigure pac if github throws error
  re-annotate the component to let it retry onboarding
• delete old branches script protects against deleting
  new branches by mistake.
• delete old branches only handles branches from the
  currently running test suite via new test env var
  called component_type which is now added to each
  test suite and checked for at run time.

Checklist before requesting a review

• I have marked as draft or added do not merge label if there's a dependency PR
  • If you want reviews on your draft PR, you can add reviewers or add the release-service-maintainers handle if you are unsure who to tag
• My commit message includes Signed-off-by: My name <email>
• I read CONTRIBUTING.MD and commit formatting

[scoheb]

/retest

[scoheb]

/retest

[johnbieren]

This PR is 177 new lines opened at the end of NA Friday (a US holiday) and merged on a Sunday, with 0 reviews. Why?

[happybhati]

❗Promoted to staging ❗

[scoheb]

This PR is 177 new lines opened at the end of NA Friday (a US holiday) and merged on a Sunday, with 0 reviews. Why?

Again. Trying to get merge queue working. A PR that was being used for testing that triggered alot of KRW tests at once showed that there was a race condition. Waiting until the following Monday to wait until NA morning to merge (providing I did not have to rebase) would have meant team members would have waiting all day on Monday with broken KRW tests until to merge. This PR only contained KRW test related changes which did not affect end users. The trade-off of not getting it approved compared to waiting and leaving a known test issue lingering seemed minor in this case.

We can have a 1x1 discussion on this topic if you prefer.

[johnbieren]

would have meant team members would have waiting all day on Monday with broken KRW tests until to merge

Not really. You could have set auto-merge and when EMEA signed on, they could approve and it would merge without you having to be online. This PR was open for 0 total working hour minutes for a single person on the team before it was merged

[scoheb]

would have meant team members would have waiting all day on Monday with broken KRW tests until to merge

Not really. You could have set auto-merge and when EMEA signed on, they could approve and it would merge without you having to be online. This PR was open for 0 total working hour minutes for a single person on the team before it was merged

with legacy e2e tests not being super reliable, the chances were slim that auto-merge would have happened.

[johnbieren]

would have meant team members would have waiting all day on Monday with broken KRW tests until to merge

Not really. You could have set auto-merge and when EMEA signed on, they could approve and it would merge without you having to be online. This PR was open for 0 total working hour minutes for a single person on the team before it was merged

with legacy e2e tests not being super reliable, the chances were slim that auto-merge would have happened.

Then a team member could have overridden that, just like you overrode even having approvals on this PR. I am not really sure why there is pushback here. A PR should not be opened and merged with no reviews and 0 working time having passed. It isn't like this sat in review for 2 weeks and had prior approvals

[scoheb]

I am not really sure why there is pushback here.

no pushback. was just trying to answer your question of "Why?"