feat(ci): only markdown action to skip some CI workflows

[kamuik16]

Related Issues

Closes #13069

Proposed Changes

• Add a new composite action Only Markdown Changed to detect when a PR modifies only .md files.
• Introduce a planner job in each workflow that runs this action and outputs only_docs.
• Update build, test, check, and docer jobs to run only if only_docs != 'true'.
• Skip all heavy CI steps automatically on docs-only PRs, cutting CI runtime and costs.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[rvagg]

@kamuik16 you've got an outdated filecoin-ffi here - I think you branched just at the wrong moment and now have the wrong ffi; rebase on to master and make the ffi change go away and 🤞 your tests should pass

[kamuik16]

@kamuik16 you've got an outdated filecoin-ffi here - I think you branched just at the wrong moment and now have the wrong ffi; rebase on to master and make the ffi change go away and 🤞 your tests should pass

Thanks @rvagg, merged master into this one.

[Copilot]

Pull Request Overview

This PR adds a composite GitHub Action to detect when a PR includes only Markdown file changes and integrates a planner job in several workflows to skip heavy CI steps for docs-only PRs.

• Added a new composite action for detecting Markdown-only changes.
• Integrated a planner job into the stale, docker, check, and build workflows to conditionally skip jobs.
• Updated workflow dependencies to run jobs only when non-doc changes are present.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
.github/workflows/stale.yml	Added a planner job and conditional trigger in the stale workflow.
.github/workflows/docker.yml	Added a planner job and corresponding if condition in the docker workflow.
.github/workflows/check.yml	Added a planner job and updated job dependencies in the check workflow.
.github/workflows/build.yml	Added a planner job and conditional step to skip build when docs-only.
.github/actions/only-markdown/action.yml	Added a composite action to determine if only Markdown files changed.

Comments suppressed due to low confidence (1)

.github/workflows/stale.yml:15

• [nitpick] Consider aligning the output variable name between the planner job (currently 'only_docs') and the composite action output ('only_markdown_changes') to improve clarity and consistency.

only_docs: ${{ steps.check.outputs.only_markdown_changes }}

[BigLep]

I'll leave to others to give approval. I wish we didn't need to make checks in every job of of a workflow, but per #13069 I didn't see any way to accomplish this, so your approach seems right.

[BigLep]

Why is this needed given .github/actions/only-markdown/action.yml is doing the checkout as well?

[kamuik16]

If this is not checked out, it shows this error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/lotus/lotus/.github/actions/only-markdown'. Did you forget to run actions/checkout before running your local action?

[kamuik16]

I have removed the checkout code from the composite action, thanks!

[BigLep]

Got it. And to be clear, it doesn't work to just put the checkout code in the composite action along and remove it from the workflow? I'm assuming not.

[BigLep]

Rather than only_docs, I wonder if we call this continue.

Would that just lets us say

if: ${{ needs.planner.outputs.continue }}

to keep it concise and to keep all the business logic inside the planner job of whether to continue (rather than leaking out this decision to whether the planner says there are only docs changes).

Not strongly held opinion, just a thought. this can always be adjusted further.

[kamuik16]

Done, addressed.

[kamuik16]

Hey @BigLep, @rvagg, I've addressed the initial comments, looking forward for your further opinions here.

[BigLep]

Thanks @kamuik16.

I wish we could reduce the boiler plate a bit more, but this seems like the best that can be done under the constraints.

Do you have an example PR that tests this to demonstrate that it works?

It seems good to me, but will leave to @rvagg to give the approval/merge.

[kamuik16]

Thanks @kamuik16.

I wish we could reduce the boiler plate a bit more, but this seems like the best that can be done under the constraints.

Do you have an example PR that tests this to demonstrate that it works?

It seems good to me, but will leave to @rvagg to give the approval/merge.

Yeah, this is the best way to achieve this under the constraints.

Do you have an example PR that tests this to demonstrate that it works?

For this, this PR itself can be an example (where non .md files changes and build/tests were ran), but I need to think some other way to test only for .md changes.

[BigLep]

but I need to think some other way to test only for .md changes.

If this isn't easy, I wouldn't worry about this. In the worst case, it's not working as desired for markdown only changes and we need to do followups.

[kamuik16]

but I need to think some other way to test only for .md changes.

If this isn't easy, I wouldn't worry about this. In the worst case, it's not working as desired for markdown only changes and we need to do followups.

I have tested the commands locally, and it works perfectly fine, and as you said, worst case, the build and test runs, if that happens, which I'm pretty sure won't, I'll fix it.