ci: Add push trigger for docker-builds

[seemethere]

Stack from ghstack:

• -> ci: Add push trigger for docker-builds #81228

Adds a push trigger for the docker-builds workflow so that docker images
will be re-built when changes that affect docker-builds get pushed

Signed-off-by: Eli Uriegas eliuriegas@fb.com

[facebook-github-bot]

🔗 Helpful links

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

✅ 1 Base Failures

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

Expand to see more

---

✅ None of the CI failures appear to be your fault 💚

---

• 1/1 broken upstream at merge base 02dfe08 from Jul 10 until Jul 11

---

🚧 1 fixed upstream failure:

These were probably caused by upstream breakages that were already fixed.

Please rebase on the viable/strict branch (expand for instructions)

If your commit is older than viable/strict, run these commands:

git fetch https://github.com/pytorch/pytorch viable/strict
git rebase FETCH_HEAD

• pull / linux-focal-py3.7-gcc7 / test (backwards_compat, 1, 1, linux.2xlarge) from Jul 10 until Jul 11 (4503c45 - 59efba3)
  • 🔁 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]

@pytorchbot merge

[pytorchmergebot]

@pytorchbot successfully started a merge job. Check the current status here

[seemethere]

@pytorchbot merge -f

[pytorchmergebot]

@pytorchbot successfully started a merge job. Check the current status here

[github-actions]

Hey @seemethere.
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.