ci: Set job-level timeout for long-running jobs

The visualstudio jobs typically take longer than the gitlab
default project-level timeout of 1h.

This can cause build failures when a fork is created as part of
a merge request, because the fork will use the default project-level
timeout.

Set a job-level timeout of 2h which will override the project-level
one according to https://docs.gitlab.com/ci/yaml/#timeout to
eliminate the need to manually adjust the project-level timeout in
forks.

Signed-off-by: Colin Baumgarten <colin.baumgarten@hubersuhner.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Merge-Request: <https://gitlab.com/libssh/libssh-mirror/-/merge_requests/826>

.gitlab-ci.yml

@@ -695,6 +695,7 @@ freebsd/openssl_1.1.1/x86_64:
 # usually timeout with the update to Gitlab 17.0
 .vs:
   stage: test
+  timeout: 2h
   cache:
     key: vcpkg.${CI_JOB_NAME}
     paths:

.gitlab/merge_request_templates/default.md

@@ -6,7 +6,6 @@ Add a description of the new feature/bug fix. Reference any relevant bugs.
  * [ ] Test suite updated with functionality tests
  * [ ] Test suite updated with negative tests
  * [ ] Documentation updated
- * [ ] The project pipelines timeout is [extended](https://docs.gitlab.com/ee/ci/pipelines/settings.html#set-a-limit-for-how-long-jobs-can-run) at least to 2 hours.
 
 ## Reviewer's checklist:
  * [ ] Any issues marked for closing are addressed

CONTRIBUTING.md

@@ -117,26 +117,6 @@ libssh Developer's Certificate of Origin for each patch, or inside each
 patch. Just the sign-off message is all that is required once we've
 received the initial email.
 
-## Continuous Integration
-
-Contributing patches through Merge Request workflow on Gitlab allows us to run
-various checks on various configuration as part of Gitlab CI. Unfortunately,
-some pipelines are slower (as they involve building dependencies) so the default
-timeout of 1 hour needs to be extended at least to 2 hours. This can be done in
-project settings of your libssh fork:
-
-https://docs.gitlab.com/ee/ci/pipelines/settings.html#set-a-limit-for-how-long-jobs-can-run
-
-Otherwise you will encounter errors like these, usually on visualstudio builds:
-
-```
-ERROR: Job failed: execution took longer than 1h0m0s seconds
-The script exceeded the maximum execution time set for the job
-```
-
-Note, that the built dependencies are cached so after successful build in your
-namespace, the rebuilds should be much faster.
-
 ## Running GitLab CI locally (optional helper)
 
 For contributors working on CI, build system changes, or adding new CI jobs, it can be useful to run GitLab CI pipelines locally before pushing.