| commit | 7463cb4c5ec2c885dad1d5f9d6ad5ec7b277981d | [log] [tgz] |
|---|---|---|
| author | Scott Todd <scott.todd0@gmail.com> | Mon Jul 22 16:05:15 2024 -0700 |
| committer | GitHub <noreply@github.com> | Mon Jul 22 16:05:15 2024 -0700 |
| tree | ecbc54f666a252ac1f1cc1d88e4d86bf57b886d0 | |
| parent | 108e050bb707dfae4e7e4d8b52759bd795b52a97 [diff] |
Move "platforms" CI jobs into their own workflow files. (#17979) This moves workflow jobs that build the full project (including the compiler) from `ci.yml` to their own workflow files: - `build_test_all_arm64` --> `.github/workflows/ci_linux_arm64_clang.yml` - `build_test_all_windows` --> `.github/workflows/ci_windows_x86_msvc.yml` - `build_test_all_macos_arm64` --> none - `build_test_all_macos_x86_64` --> `.github/workflows/ci_macos_x86_clang.yml` With one workflow file per platform, these are the tradeoffs compared to a single workflow file: Pros: + Easy to tune which triggers affect each workflow * See https://github.com/Tencent/ncnn/blob/master/.github/workflows/windows-clang.yml for some inspiration. Each workflow can independently define `paths:` to trigger on. We have support for that via [`build_tools/github_actions/configure_ci.py`](https://github.com/iree-org/iree/blob/main/build_tools/github_actions/configure_ci.py), but this also allows for adjusting schedule triggers too. + Easy to fork a workflow for a new platform, less merge conflicts in a single large file + Easy to cancel a single job without affecting others from the same file + Easy to disable/enable a workflow in isolation from the UI if there are runner issues + Low impact radius if/when a single platform has runner issues Cons: - If running on PRs, checks are spread out a lot - Hard to mark multiple/all jobs as required checks (if we care) - More code duplication between files (reusable workflows can help here... maybe, could also lean on CMake presets and build scripts) Practically at this point in time, these workflows _were_ running on all commits pushed to the `main` branch but they were disabled for being too slow or requiring runners that went offline. Now the workflows will run on a nightly schedule and they can be disabled individually from the GitHub UI as needed. TBD how we'll make these workflows available for opt-in on presubmit. We could add the `pull_request` trigger back, trigger if some labels are added, etc. skip-ci: adding new workflows, existing ones are unaffected
IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.
See our website for project details, user guides, and instructions on building from source.
IREE is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!
See our website for more information.
Community meeting recordings: IREE YouTube channel
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.