missing includer issue

[aminya]

EDIT: fixed in aminya/CompileBot.jl#5

To fix missing includer issue in JuliaPlots/Plots.jl#2838

⚠️ emergency patch

• Adds gitattributes to prevent line ending changing during uploads from different operating systems
• removes previous bash script that did a similar thing
• throws an error for anyone who uses the bash script (there is no other way to let them know 😞)

Let's merge this before people run into the same issue.

[aminya]

@timholy "Lost of methods" tests fail in the nightly. Has anything changed in nightly?

[aminya]

I wonder if f50b27a actually fix the issue. The bash script for discarding whitespace changes is very hacky and unreliable. I prefer to write a Julia script to achieve the goal.

Running it on https://github.com/JuliaPlots/Plots.jl/suites/862271274/artifacts/9944298, solves the issue, but we might want to test it on more packages.

This is a patch that we cannot send to our users unless we find all the repositories that use SnoopCompile.yml. 😞 This line of code was added as a workaround for actions/upload-artifact#75. But now it is a wrecker for the packages that rely on precompilation so much that without it they break (e.g Plots).

We should take #99 serious now. Probably adding a warning to snoop_bot and snoop_bench to update their workflow files, and use GitHubActions.jl to bring it to their notice:

using Logging: global_logger
using GitHubActions: GitHubActionsLogger
get(ENV, "GITHUB_ACTIONS", "false") == "true" && global_logger(GitHubActionsLogger())

[aminya]

@timholy Could you take a look at this?

[timholy]

Hmm, messing with a repo's git attributes seems beyond the scope of SnoopCompile, and it seems like material better placed in PkgTemplates than here. Is there a more minimal fix possible?

[aminya]

Hmm, messing with a repo's git attributes seems beyond the scope of SnoopCompile, and it seems like material better placed in PkgTemplates than here. Is there a more minimal fix possible?

Yes, it should be in PkgTemplates too, but specifically for this case, we need some sort of EOL managing. One way I can think of is to have a SnoopCompileBot.post_generation function that runs in the Create_PR step, and we can do some post generation checks or fixes in it. Such as fixing line-ending issues, checking the existance of includer, or any compatibility things that may arise later.

[timholy]

I'd like this to be as small & non-intrusive a fix as possible for this bug, and then let's split the bot out into a separate package and you can do more heroic repo-surgery there.

[timholy]

Or alternatively, if it really is hard to fix this without something big (notifying all existing users, whatever), then let's just do the split now and you can fix in 2.0?

[aminya]

As I said already, I am OK with splitting the bot into a separate repository. We can do it at any time.

For later fixes, I want to add that post_generation function to refactor the Create_PR step in SnoopCompile.yml.

Currently, I have to error to inform the users about the faulty bash script. That only affects the users of multios/multiversion configuration. We should fix this now before switching to 2. We should have a working 1.x release.

[timholy]

As mentioned above, I don't plan to merge this before we switch to 2.0. Changing the git settings on the repo by default is beyond the scope of this package. I recommend creating the new bot repo package soon.