[k2] increase timeout for phpt tests

[PetrShumilov]

Previously, we didn't have timeout for phpt tests. After #1569 merging we have. In order to prevent flaky in k2 phpt tests need to increase timeout up to 600 sec.

[apolyakov]

In my opinion, this is not enough. It's fine to increase the timeout, but it still slows down all the CI runs. Moreover, as far as I see it may generate too much logs which may affect CI agents' disk space.

Alternatively we may have an option to run our CI with builtin functions coverage statistics enabled. It may be done on demand or, for example, on each merge to master.

Also, it may be better to have an option to customise task_hard_timeout

[PetrShumilov]

In my opinion, this is not enough. It's fine to increase the timeout, but it still slows down all the CI runs. Moreover, as far as I see it may generate too much logs which may affect CI agents' disk space.

Alternatively we may have an option to run our CI with builtin functions coverage statistics enabled. It may be done on demand or, for example, on each merge to master.

Also, it may be better to have an option to customise task_hard_timeout

No related to this PR

[apolyakov]

In my opinion, this is not enough. It's fine to increase the timeout, but it still slows down all the CI runs. Moreover, as far as I see it may generate too much logs which may affect CI agents' disk space.
Alternatively we may have an option to run our CI with builtin functions coverage statistics enabled. It may be done on demand or, for example, on each merge to master.
Also, it may be better to have an option to customise task_hard_timeout

No related to this PR

Why not? Should we think of this PR as of temporary solution?

[PetrShumilov]

In my opinion, this is not enough. It's fine to increase the timeout, but it still slows down all the CI runs. Moreover, as far as I see it may generate too much logs which may affect CI agents' disk space.
Alternatively we may have an option to run our CI with builtin functions coverage statistics enabled. It may be done on demand or, for example, on each merge to master.
Also, it may be better to have an option to customise task_hard_timeout

No related to this PR

Why not? Should we think of this PR as of temporary solution?

ofc