Pulled out lint+docs as its own workflow; Other workflows ignore docs folder

[vineetbansal]

If we are to skip regular testing (unpinned or pinned) on changes to docs/, the cleanest solution seems to be to pull it out as its own workflow (github allows ignoring at the workflow level, otherwise the if conditions get messy).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.42%. Comparing base (463d80b) to head (3a62980).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #340   +/-   ##
=======================================
  Coverage   86.42%   86.42%           
=======================================
  Files          14       14           
  Lines        1856     1856           
  Branches      322      322           
=======================================
  Hits         1604     1604           
  Misses        207      207           
  Partials       45       45           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rkingsbury]

Thanks @vineetbansal . Is there any way to make one workflow depend on the outcome of another? (e.g., only run testing if lint passes?

If not, I'm ok with this as-is. It looks like this will make lint and docs always run, but testing will not run if only docs/ or CHANGELOG were modified

[vineetbansal]

I think this latest change will work - the testing* workflows essentially re-use the lint_and_docs workflow, and the checks show up as :

[testing / lint-and-docs / docs (pull_request)]
[testing-pinned / lint-and-docs / docs (pull_request)]
...

Since the lint-and-docs is not / should not be run independently, I've removed the trigger from it, but it only runs on workflow_call.

Claude Code helped me refactor this, and it looks like it was correct. However, one of the links through linkcheck seems to have broken in the meantime, so I need to fix it.

[rkingsbury]

However, one of the links through linkcheck seems to have broken in the meantime, so I need to fix it.

Oh, I think that's coming from a link in a docstring that Shaun added in #317 , but it's only a warning triggered by a redirect

/home/runner/work/pyEQL/pyEQL/docs/class_solution.md:57: WARNING: redirect  https://doi.org/10.21203/rs.3.rs-8743330/v2 - with Found to https://www.researchsquare.com/article/rs-8743330/v2

Can we suppress or ignore that type of warning in the link check? I don't think it makes sense to fail the docs test just because some links use redirects (and we will use a lot of DOI links, which almost always redirect)

[rkingsbury]

This is great! Now that you (and Claude Code!) figured this out, can you move docs into a completely separate workflow, so that testing requires lint to pass but not docs? This PR provides a nice example - it seems unnecessary for tests not to run just because of a docs warning, but I do want to make sure linting passes before testing runs.

This looks like it will be straightforward to do, given the architecture you've created for lint_and_docs

[vineetbansal]

@rkingsbury - I've split the lint_and_docs workflows - hopefully this passes.

For the redirect check - I feel like once we've said that we're treating warnings like errors, we shouldn't ignore any warnings (better to not treat them as errors if we're going that way). For redirects, its usually easy to fix these one-off warnings as we encounter them. I've fixed the one we just encountered. However, if this becomes a constant CI headache with DOI links, then perhaps we can tackle this later as an isolated issue?

[vineetbansal]

EDIT: I think I now remember a similar issue from another project. Is our concern that we would rather link to doi.org than commit to resolving the link any further?

[rkingsbury]

EDIT: I think I now remember a similar issue from another project. Is our concern that we would rather link to doi.org than commit to resolving the link any further?

Exactly! I generally consider the DOI links to be the "canonical" and more permanent ones.

[rkingsbury]

(and yes, happy to tackle that in another issue; I don't expect it will come up that often)