rules_xcodeproj
rules_xcodeproj copied to clipboard
Feature Request: Pre/Post build phases
This allows integrating linting/formatting tools into your Xcode project to get warnings and errors displayed in the issue navigator.
Unlike pre/post actions, additional build phases don't belong to schemes, but to targets.
- [x] Pre-build with BwB: https://github.com/buildbuddy-io/rules_xcodeproj/pull/1117
- [x] Post-build with BwB: https://github.com/buildbuddy-io/rules_xcodeproj/pull/1129
- [ ] Pre-build with BwX
- [ ] Post-build with BwX
This allows integrating linting/formatting tools into your Xcode project to get warnings and errors displayed in the issue navigator.
Unlike pre/post actions, additional build phases don't belong to schemes, but to targets.
I have some questions for you, @BalestraPatrick, and @erikkerber: Is this what these are going to be for? Just pre and post "build" (not target-compile) linting/formatting? I want to make sure I understand the full scope of what is asked for, since there seems to be some confusion in the discussion in #1117.
If linting, is there a reason it's not part of the build itself, using Validation Actions? If formatting, it will need to happen before Bazel Build
so the changes are picked up before Bazel starts (so definitely not pre target-build). If it's something that needs to happen before or after a target builds that is tricky/nearly right now, and would require some BEP integration to get right (and it has to be non-source affecting per the previous statement).
Notably pre-build specifically for something like swiftlint, so the linting errors can be output into the Xcode IDE before any potentially long completion step. Aside from that, it's just a point in the build we can print output that Xcode renders inline as warnings/errors. This is not for any autofix system.
I'm assuming this use case won't work in a pre-scheme action, but I admit I've never tried either.
I'm assuming this use case won't work in a pre-scheme action, but I admit I've never tried either.
I believe Xcode still doesn't render the output from scheme pre-build actions, so this is correct.
I believe the main use case is linting in the IDE for developers. We used to have this with Tulsi and lost the ability to run swiftlint lint --reporter xcode
from a build phase to show in-line violations. I was not aware of validation actions, and at the moment we have some scripts that run various linters manually.
Let me break this down to get the feature we need in first:
- [x] Pre-build with BwB (resolved by #1117)
- [x] Post-build with BwB (resolved by #1129)
- [ ] Pre-build with BwX
- [ ] Post-build with BwX
If linting, is there a reason it's not part of the build itself, using Validation Actions?
We still have the linting process running outside of the Bazel context, and only run it in the IDE.