Lower timeout-minutes.

[vincentmr]

Before submitting

Please complete the following checklist when submitting a PR:

• All new features must include a unit test.
  If you've fixed a bug or added code that should be tested, add a test to the
  tests directory!

• All new functions and code must be clearly commented and documented.
  If you do make documentation changes, make sure that the docs build and
  render correctly by running make docs.

• Ensure that the test suite passes, by running make test.

• Add a new entry to the .github/CHANGELOG.md file, summarizing the
  change, and including a link back to the PR.

• Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

---

Context:
Windows workflows sometimes get stuck at some step and times out after 6 hours.

Description of the Change:
Lower timeout on all workflows to avoid this situation.

Benefits:
Fail faster.

Possible Drawbacks:

Related GitHub Issues:

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +54.18% 🎉

Comparison is base (6b8dbac) 44.52% compared to head (4cc2c16) 98.71%.

Additional details and impacted files

@@             Coverage Diff             @@
##           master     #503       +/-   ##
===========================================
+ Coverage   44.52%   98.71%   +54.18%     
===========================================
  Files          23      142      +119     
  Lines        1179    16798    +15619     
===========================================
+ Hits          525    16582    +16057     
+ Misses        654      216      -438     

Files Changed	Coverage Δ
pennylane_lightning/core/_version.py	100.00% <100.00%> (ø)

... and 135 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AmintorDusko]

Did you test the wheels we build only when merging to master? (edit: I'm asking because maybe I'm missing something here) The Wheel::Linux::ARM for example can sometimes take more than 30 min. I think we could only limit the Windows runners since they are the problematic ones. What do you think?

[vincentmr]

Did you test the wheels we build only when merging to master? (edit: I'm asking because maybe I'm missing something here) The Wheel::Linux::ARM for example can sometimes take more than 30 min. I think we could only limit the Windows runners since they are the problematic ones. What do you think?

I think it good to have time limit on each job, to set expectations but also avoid wasting time in some cases. While we have an idea how long each job should take, new hires, contributors from other teams and external contributors don't. So I'd like to introduce timeouts and revise them as required. For wheel_linux_aarch64, I think you may be right, so I would just increase it to 45 minutes.

[vincentmr]

I should note too that there are 30 minutes for building Kokkos and 30 minutes for the wheels, but I can still increase it a bit just in case.

[mlxd]

Let's set these as 45 mins -- enough time to have a safety margin, and short enough to kill a task that runs over ahead of the 6 hr window.

[AmintorDusko]

Hey @vincentmr, thank you for that! Please triple-check the CIs building wheels only when merging.

[mlxd]

Thanks @vincentmr