validation tests: make the time constraints more generous

[TomasTomecek]

Last two days, two validation checks failed even though all GitHub check runs were green after some time:

https://github.com/packit/hello-world/runs/6587387284
https://sentry.io/share/issue/3d1ddfb488cd40eaae3550af18f15d00/
https://sentry.io/organizations/red-hat-0p/issues/3297006723/?referrer=alert_email&alert_type=email&alert_timestamp=1653371582691&alert_rule_id=855946&environment=production

Let's make the time limits more generous and aligned with our actual OKRs.

Example: check Basic test case: copr build and test (https://github.com/packit/hello-world/pull/648) failed: These check runs were not completed 20 minutes is too strict.

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[TomasTomecek]

I added this to the top of our jira backlog

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[stale]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[mfocko]

Update on the issue

Currently we we're at 30 minutes… I see some failures in the Sentry, but it appears they are caused by the fact we have some deprecated targets in the PRs that we reuse (apparently got into pending sometime around branching and got stuck…) :/

[mfocko]

Based on the discussion on the architecture (a week ago), we agreed on keeping the current timeout and changing it further, if required. Therefore closing this issue as done, since the timeout has already changed from the reporting.