Pin cmake version to workaround pytorch build issues

[xuzhao9]

We need to pin the cmake version to workaround pytorch build issue.

See details at: #74985

[facebook-github-bot]

🔗 Helpful links

• 🧪  See artifacts and rendered test results at hud.pytorch.org/pr/75045
• 📄  Preview Python docs built from this PR
• 📄  Preview C++ docs built from this PR
• ↩️  [fb-only] Re-run with SSH instructions
• ❓Need help or want to give feedback on the CI? Visit our office hours

💊 CI failures summary and remediations

As of commit b4bb92c (more details on the Dr. CI page):

---

• 3/3 failures introduced in this PR

---

🕵️ 1 new failure recognized by patterns

The following CI failures do not appear to be due to upstream breakages

pull / linux-xenial-cuda11.3-py3.7-gcc7-bazel-test / build-and-test (1/1)

Step: "Test" (full log | diagnosis details | 🔁 rerun)

2022-03-31T23:12:16.4683385Z �[36;1m echo "ERR...t available for the merge-base of your branch"�[0m

2022-03-31T23:12:16.4680365Z �[36;1mfi�[0m
2022-03-31T23:12:16.4680590Z �[36;1m# Covers the case where a previous tag doesn't exist for the tree�[0m
2022-03-31T23:12:16.4680934Z �[36;1m# this is only really applicable on trees that don't have `.circleci/docker` at its merge base, i.e. nightly�[0m
2022-03-31T23:12:16.4681325Z �[36;1mif ! git rev-parse "$MERGE_BASE:.circleci/docker"; then�[0m
2022-03-31T23:12:16.4681663Z �[36;1m  echo "Directory '.circleci/docker' not found in commit $MERGE_BASE, you should probably rebase onto a more recent commit"�[0m
2022-03-31T23:12:16.4681941Z �[36;1m  exit 1�[0m
2022-03-31T23:12:16.4682104Z �[36;1mfi�[0m
2022-03-31T23:12:16.4682324Z �[36;1mPREVIOUS_DOCKER_TAG=$(git rev-parse "$MERGE_BASE:.circleci/docker")�[0m
2022-03-31T23:12:16.4682752Z �[36;1m# If no image exists but the hash is the same as the previous hash then we should error out here�[0m
2022-03-31T23:12:16.4683058Z �[36;1mif [[ "${PREVIOUS_DOCKER_TAG}" = "${DOCKER_TAG}" ]]; then�[0m
2022-03-31T23:12:16.4683385Z �[36;1m  echo "ERROR: Something has gone wrong and the previous image isn't available for the merge-base of your branch"�[0m
2022-03-31T23:12:16.4683779Z �[36;1m  echo "       contact the PyTorch team to restore the original images"�[0m
2022-03-31T23:12:16.4684012Z �[36;1m  exit 1�[0m
2022-03-31T23:12:16.4684174Z �[36;1mfi�[0m
2022-03-31T23:12:16.4684358Z �[36;1mecho ::set-output name=rebuild::yes�[0m
2022-03-31T23:12:16.4695068Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2022-03-31T23:12:16.4695286Z env:
2022-03-31T23:12:16.4695430Z   IN_CI: 1
2022-03-31T23:12:16.4695589Z   IS_GHA: 1
2022-03-31T23:12:16.4695769Z   GIT_DEFAULT_BRANCH: master
2022-03-31T23:12:16.4695997Z   BASE_REVISION: 8d69254dfdaacc21a6547e69e7baae5156d33d4a

---

🕵️‍♀️ 2 failures not recognized by patterns:

The following CI failures may be due to changes from the PR

Job	Step	Action
pull / linux-bionic-rocm5.0-py3.7 / test (default, 1, 2, linux.rocm.gpu)	Checkout PyTorch	🔁 rerun
pull / linux-bionic-rocm5.0-py3.7 / test (default, 2, 2, linux.rocm.gpu)	Unknown	🔁 rerun

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[seemethere]

Maybe a good follow up to this would be to just pin all of these particular dependencies

[xuzhao9]

One problem of doing that is we need to keep consistent with pytorch/benchmark workflows such as in https://github.com/pytorch/benchmark/blob/main/.github/workflows/v2-bisection.yml#L31. Perhaps it is better to create a script in pytorch/benchmark to manage these dependencies in a unified manner.

[xuzhao9]

@pytorchbot merge this

[github-actions]

Hey @xuzhao9.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.