Create Invalidations.yml

[ranocha]

This is based on https://github.com/julia-actions/julia-invalidations. Adding such checks came up in https://discourse.julialang.org/t/potential-performance-regressions-in-julia-1-8-for-special-un-precompiled-type-dispatches-and-how-to-fix-them/86359. I suggest to add this check here since this package is widely used as a dependency.

See also SciML/MuladdMacro.jl#26 and SciML/MuladdMacro.jl#29

[codecov[bot]]

Codecov Report

Merging #259 (5192a57) into master (51b1838) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #259   +/-   ##
=======================================
  Coverage   93.08%   93.08%           
=======================================
  Files           6        6           
  Lines         767      767           
=======================================
  Hits          714      714           
  Misses         53       53           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[ranocha]

Bump

[kimikage]

I don't see a problem with this per se, but I do have a question as to who this is for. More precisely, the question is: Who will maintain the invalidation issues?

[ranocha]

Whoever makes a PR increasing the number of invalidations has a chance to look at them?

[kimikage]

Since this package is relatively low-level, I think invalidation is a julia problem unless writing "too rude" code. Unlike code coverage, it is not a rewarding index...

[kimikage]

The versions of several actions are outdated, but I will rely on dependabot.

[kimikage]

Although this PR was merged under my responsibility, this workflow brought the very useful feature of :x:-marking new PRs. :tada:

More precisely, the question is: Who will maintain the invalidation issues?

cf. https://github.com/julia-actions/julia-invalidations/issues/17

[kimikage]

workaround: #287