114f48e96c
[Bazel] Check cache directory exists before changing owners ( #1241 )
...
This fixes a seeding issue with the [previous PR](https://github.com/llvm/torch-mlir/pull/1240 ) where bazel build's GHA cache is not present to begin with and one of the commands (chown) fails on it. Should get the Bazel build back to green.
2022-08-17 17:04:50 -07:00
9c8b962720
Dockerize and Cache Bazel {Local, CI} Builds ( #1240 )
...
This PR adds:
- A minimal docker wrapper to the bazel GHA workflow to make it reproducible locally
- Bazel cache to speed up GHA workflows (down to ~5 minutes from ~40+minutes)
This is a no-op for non-bazel workflows and an incremental improvement.
2022-08-17 12:46:17 -07:00
34478ab1c7
[Build] Add concurrency groups to address long queue times ( #1219 )
...
We're seeing large CI queue times ([example](https://discord.com/channels/636084430946959380/742573221882364009/1007631811184164944 )) especially with MacOS VMs on GHA. Part of the problem is follow-on commits to the same branch which trigger new runs while the previous runs are still in-progress, hogging on the scarce VMs.
This PR adds concurrency groups to the GHA workflow which ensures that only a single job or workflow using the same concurrency group will run at a time. This would cancel any in-progress jobs in the same github workflow and github ref (e.g. `refs/heads/main` or `refs/pull/<pr_number>/merge`).
As discussed on discord [thread](https://discord.com/channels/636084430946959380/1007787336848912386/1007787338895740928 ), once this lands we may have to closely monitor the workflows to see this didn't introduce unintended consequences. If so, we could either revert, or decide to selectively cancel particular runs (e.g. macos only which is the main bottleneck right now) instead of entire workflow.
This will also require some expectation management. As in, if you see an ❌ on the main branch, it may not necessarily mean things broke, it could mean the run was killed by a more recent run. Making it a bit harder to traceback a failure to a commit in a sequence of commits (requiring to run those builds again).
Thanks @powderluv for the proposal and pointer to this! It should help with the scarce VMs on GHA and save on queue time.
References:
* https://docs.github.com/en/actions/using-jobs/using-concurrency#example-only-cancel-in-progress-jobs-or-runs-for-the-current-workflow
* https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-only-cancel-in-progress-jobs-or-runs-for-the-current-workflow
2022-08-12 17:38:48 -07:00
f00ca91db0
Simplify matrix configuration for CI workflows ( #1213 )
...
Addresses https://github.com/llvm/torch-mlir/issues/1207 .
#### Provisioned jobs:
```
# ubuntu - x86_64 - llvm in-tree - pytorch binary - build+test # most used dev flow and fastest signal
# ubuntu - x86_64 - llvm out-of-tree - pytorch source - build+test # most elaborate build
# macos - arm64 - llvm in-tree - pytorch source - build only # cross compile, can't test arm64
```
#### Main changes
- [x] Spawn macos builds from a separate matrix (in the same workflow). It made sense to do this as they are fairly different from ubuntu (cross compile, use a different cmake configuration). This simplifies the matrix configuration and exclusions quite a bit, and makes the workflow a bit more tractable and maintenance friendly.
- [x] Remove the submodule md5sum step for ccache config. This was [broken](https://github.com/llvm/torch-mlir/runs/7779288734?check_suite_focus=true#step:3:145 ) for a while now.
- [x] Removes unused matrix options - `os`, `targetarch`, `python-version`, `llvmtype`.
- [x] Address ZSTD [comment](https://github.com/llvm/torch-mlir/pull/1204#discussion_r942349282 ) on @powderluv's cross compile [PR](https://github.com/llvm/torch-mlir/pull/1204 ).
#### Further improvements (to be addressed in follow-on):
* ubuntu-x86_64 out-of-tree integration tests fail ([error](https://github.com/sjain-stanford/torch-mlir/runs/7781264029?check_suite_focus=true )); only run unit tests for now (tests are excluded in current CI too)
#### Passing workflow:
https://github.com/sjain-stanford/torch-mlir/actions/runs/2840676309
2022-08-11 16:35:15 -07:00
d41c7becf5
[Bazel] Allow workflow_dispatch manual trigger on bazel workflow ( #1203 )
...
At the moment we don't gate torch-mlir PRs with bazel builds. This means bazel builds don't get run on open PRs, and so there's no good way to validate a fix PR which is meant to fix a broken bazel build. This option allows a bazel build to be manually triggered as needed on open PRs.
2022-08-09 13:28:21 -07:00
6b3d0b7e7a
Add bazel build support (2/N) ( #744 )
...
- Add bazel GitHub actions.
2022-04-25 12:33:15 -07:00
Sambhav Jain
Ahmed S. Taei
