File Header rule fails on CI

[jesus-mg-ios]

Hi I'm comming up with an error on xcode cloud trying to use the new {created.date}.

The rules I'm using are:

--exclude .somefolders/
--wraparguments before-first
--wrapcollections before-first
--disable trailingClosures
--disable wrapMultilineStatementBraces
--disable initCoderUnavailable
--maxwidth 120
--header "\n{file}\nCopyright (c) {created.date} company. All rights reserved.\nCreated by company.\n"

The first step was adding in the script: git fetch --unshallow

After that, the complaining count went down.

Using same version on local and CI, but when you run lint, for only some files swiftformat complains. (after doing git fetch --unshallow less files were affected) :

filePath..... 
-- rules applied: fileHeader

SwiftFormat completed in time's.
Source input did not pass lint check.

Any idea on how to deal with this would be much appreciated.

[nicklockwood]

cc @hampustagerud - any idea what the problem is here?

[nicklockwood]

@jesus-mg-ios FYI I think {created.date} needs to be {created.year}, although that may not be the cause of your issue

[jesus-mg-ios]

@jesus-mg-ios FYI I think {created.date} needs to be {created.year}, although that may not be the cause of your issue

Sorry for the mistake, same result using {created.year}

[bcybs]

Same issue - however what I'm experiencing but never noticed before is that when I run swiftformat . on the project with {created.year} in the header template it sets every file to the current year. Perhaps this is the issue - it's now working as expected on CI but from SwiftFormat it's setting the current year not the created year?

[nicklockwood]

@bcybs prior to the git integration added in the last release, the created date was derived from the file metadata. For files stored in git, that probably ends up being the checkout date rather than the original creation date.

[hampustagerud]

If the repo is checked out with only one commit (--depth 1) then that will be the commit creating the file, which is most likely why the errors are thrown. I am not sure what the best solution would be but some of them include:

• Document the issue and solutions (see last paragraph)
• Fail in shallow git clones (could be checked with git rev-parse --is-shallow-repository)
  • Requiring unshallow clones might work since repos with a long history might be too big to clone in a reasonable time
  • Along with some helpful hints in the error message, and documentation in the README, this would maybe be the best solution?
• Default to the file metadata
  • Doesn't support all placeholders, not guaranteed to match the committed values
• Allow any value for the placeholder when linting
  • Does not fail on incorrect values for the placeholders
• Scope the git stuff behind a .git placeholder (e.g {git.created} or something) and document the caveats of using it
  • Not really a solution that solved the problem, only helps out with solving it

If I were to implement a CI with this I'd try with replacing git clone --depth 1 ... with git clone --filter=blob:none .../git clone --filter=tree:0 ... to avoid cloning everything (for speed) but keeping the entire history 🙂 more info