| commit | 09f54d811b864ed06d370ca27d8759517141d024 | [log] [tgz] |
|---|---|---|
| author | Geoffrey Martin-Noble <gcmn@google.com> | Fri Jul 07 10:00:02 2023 -0700 |
| committer | GitHub <noreply@github.com> | Fri Jul 07 10:00:02 2023 -0700 |
| tree | 41ec597957c8b3277a926ce429fd4b5ee0ce94c0 | |
| parent | 89919da969d6a18777618ceda7cddc9d9cd3c401 [diff] |
Implement CI job optionality (#14312) With an increasing number of CI jobs and more resource issues, I think it's useful for people to be able to specify which jobs they actually want to run. In particular, I think it would be beneficial to make some jobs, such as Windows, Mac, and A100, available for opt-in. Personally, when adding new jobs, I am routinely hacking the ci.yml file to only run specific jobs and I think I am probably better able to do that: I see other people running the entire workflow repeatedly just to test one job. Now that we re-evaluate the PR description when rerunning the job, people don't need to push another commit or anything after editing the description: they can 'just' cancel and rerun the job (still not ideal). I know people have struggled with the ergonomics of trailers for CI control in the past. I tried to make the tag names follow a consistent format and also added additional error checking like looking for unknown usage of reserved prefixes. Weird tag combinations provide immediate errors. The lack of correspondence between `skip-ci` and `ci-skip` is a bit unfortunate. I'm open to other names, but I don't think we should choose something less natural just to avoid this. We should probably drop `skip-ci` entirely with this because you would spell that `ci-skip: all`. That does have the disadvantage of not being able to provide justification as part of the trailer, but that can be done free-form in the PR description without losing much IMO. One thing this doesn't do is any kind of dependency analysis. That is, if you specify `ci-exactly: test_all`, it's not going to run `build_all` and then the `test_all` job will just fail. This is theoretically something it could do, since it's already parsing the workflow file, but I'm not sure if that actually makes things less confusing. This also perhaps prompts cleaning up the job names so they're a bit pithier and more intuitive. I think `build_test_all_windows` could just be called `windows` for instance: this is a case where very structured names actually get in the way IMO. Fixes https://github.com/openxla/iree/issues/10042 Tested running locally with various env variable settings. Tested a few different options in this PR also. ci-skip: all
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.
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.