Missing debug information on CI jobs print about "mark comment for a type"
Hey team, seems we ran into an issue that sometimes our gitlab CI jobs failed with only one statement:
ERROR: Job failed: exit status 1 without any additional information about the violations.
What we found:
- When we run the checks locally, it looks fine without any failed prints.
- Seems it should be related to
mark comment for a typeas we runmint run --no-install SwiftFormat --strict .locally and it will add theMARK: - .....
Not too sure it is an issue or just expected behaviour here. 🙏
Are you running SwiftFormat with the --lint argument in CI?
@nicklockwood thanks for the followup
I had a check on our script. it is mint run --no-install SwiftFormat --lint --strict .
Status 1 is lint failure, which makes sense if the code has not been formatted. Maybe the issue is that the actual violation messages are not being passed on by your CI? I don't know enough about gitlab to know the best approach to take there though.
yea, there is no actual violation messages are being passed/displayed on by our CI job console. Thanks for the replies here anyway 😃
Sorry if this seemed like I was stating the obvious 😅 What I meant was, I think the problem may be that the messages aren't being passed on, rather than that SwiftFormat isn't actually producing any useful messages.
The violation messages are typically written to stderr rather than stdout, if that's any help.
all good, good to know that, will have a look 🙏
I've included a reproduction of the issue below, haven't confirmed 100% but it seems that if markTypes is the only violations - they do not print an error.
brettbest@Bretts-MacBook-Pro ~/D/SwiftFormat-Reproduction [0|1]> printf "struct MyStruct {}\n\nextension MyStruct {}" | mint run nicklockwood/[email protected] --enable all --lint --strict stdin
Running SwiftFormat...
(lint mode - no files will be changed.)
:3:1: error: (linebreakAtEndOfFile) Add empty blank line at end of file.
:3:1: error: (markTypes) Add a MARK comment before top-level types and extensions.
Source input did not pass lint check.
brettbest@Bretts-MacBook-Pro ~/D/SwiftFormat-Reproduction [0|1]> printf "struct MyStruct {}\n\nextension MyStruct {}\n" | mint run nicklockwood/[email protected] --enable all --lint --strict stdin
Running SwiftFormat...
(lint mode - no files will be changed.)
Source input did not pass lint check.
For the last command I would expect the output to be:
brettbest@Bretts-MacBook-Pro ~/D/SwiftFormat-Reproduction [0|1]> printf "struct MyStruct {}\n\nextension MyStruct {}\n" | mint run nicklockwood/[email protected] --enable all --lint --strict stdin
Running SwiftFormat...
(lint mode - no files will be changed.)
:3:1: error: (markTypes) Add a MARK comment before top-level types and extensions.
Source input did not pass lint check.
@nicklockwood let me know if this might need to be a separate issue but the below doesn't produce a violation - not sure if the Rules.md doesn't have the correct default values 🤔
brettbest@Bretts-MacBook-Pro ~/D/SwiftFormat-Reproduction [0|1]> printf "struct MyStruct {}\n" | mint run nicklockwood/[email protected] --enable all --lint --strict stdin
Running SwiftFormat...
(lint mode - no files will be changed.)
SwiftFormat completed successfully.
@Brett-Best that certainly seems like a bug - thanks for the repro case!
@nicklockwood let me know if this might need to be a separate issue but the below doesn't produce a violation - not sure if the
Rules.mddoesn't have the correct default values 🤔brettbest@Bretts-MacBook-Pro ~/D/SwiftFormat-Reproduction [0|1]> printf "struct MyStruct {}\n" | mint run nicklockwood/[email protected] --enable all --lint --strict stdin Running SwiftFormat... (lint mode - no files will be changed.) SwiftFormat completed successfully.
@Brett-Best this is actually the expected behavior - markTypes doesn't add a MARK comment if there is only one top-level declaration in the file.
@Brett-Best fixed in 0.54.3
@alvinh77 I'm not sure if we actually established whether the problem Brett found was the cause of your issue or not? If it's not fixed in 0.54.3 please feel free to reopen the issue