2010YOUY01 commented on PR #23414: URL: https://github.com/apache/datafusion/pull/23414#issuecomment-4953591926
> I'm trying to get a bigger picture. When we say `rust` CI does it mean to run locally the flow `.github/workflows/rust.yml`? if it is I would recommend again to look into [apache/datafusion-comet#4570](https://github.com/apache/datafusion-comet/pull/4570), so the contributor would run the flow in their own repo without having a local clone. > > Do we anticipate supporting 2 flows might be hard to maintain and keep them in sync and eventually the local part might be untrusted and not used as the result? 🤔 > > If the end goal to catch issues as early as possible or save ASF resources then contributor forks delegation would help, otherwise we may want to try to break down `rust.yml` into more manageable parts and have critical part for testing in separate, locally testable yml 1. Regarding the end goal: Another important goal is faster local checks. GitHub-hosted runners can be slow, especially for forks, while local runs can be much faster. This also saves time otherwise spent fixing CI failures: we can simply ask a coding agent to run the local CI suite on the final commit before opening a PR, I found checking Github CI status after sending PR, and potentially fix it later is particularly annoying, and this can be avoided. I think this is actually the more important motivation. 2. Regarding maintenance: After experimenting with this approach, I have two observations: 1. Moving the shell scripts to a Rust-based `cargo xtask` solution has already reduced the maintenance burden. In general, I find it more ergonomic to maintain. 2. Personally, I think keeping the local CI runner and GitHub Actions in sync will be actually simple. Most critical tests require only the Rust toolchain. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
