Add optional flag to use “[skip ci]” commits as BASE SHA instead of last successful workflow run

[ak274]

nx-set-shas currently determines the BASE SHA by locating the last successful CI workflow run on your main branch (or falling back to HEAD~1 or a provided fallback SHA) and always uses that commit as the “base” for nx affected calculations . In our release pipeline we insert version-bump and changelog commits annotated with [skip ci] (or [ci skip]) after the last successful workflow run. Because those commits never generate a “successful” workflow, nx-set-shas continues to pick the older workflow’s commit instead of the more recent skip-ci commit, causing our affected diff to miss changes introduced during versioning.

Current behavior

On push events to main, the action runs findSuccessfulCommit(...) to retrieve the last successful workflow run’s SHA via GitHub’s Actions API .

If none is found, it warns (or errors if error-on-no-successful-workflow: true) and falls back to either fallback-sha or HEAD~1/empty-tree .

It never considers commits marked [skip ci], because those never report “success” to the Actions API .

Desired behavior

We’d like an optional input flag, e.g. use-skip-ci-commits-as-base, which when set to true will:

Scan the main branch’s commit history for the most recent commit whose message matches /[(ci skip|skip ci)]/i.

Use that commit’s SHA as BASE before falling back to the existing “last successful workflow” logic.

Preserve current behavior when the flag is false or unset.

[JamesHenry]

To confirm the logic here for maxmium correctness:

• We should find the most recent successful commit as normal on the specified branch (e.g. main)

• If the new option is enabled, we should then additionally check for if there have been any commits on that same branch after this commit which had skipped CI due to the special comment. If there is one immediately after our latest successful run we should use that as NX_BASE.

• We should not simply check the option and find the most recent skipped CI due to the special comment (because this could have happened before a subsequent successful run).

• We should not check more than one subsequent commit after the latest successful commit because the following would be possible:

  • Successful main CI
  • Broken main CI based on some new changes
  • Skipped main CI due to a release
    ...and in this case we would miss out the changes in step 2 if we did it that way.

Does that all make sense? Am I missing anything?

---

@r0manchak @ejasarevic @drodarie @eXigentCoder @daltonmcphaden @yann510 Interested in your feedback too please, as you appear to have previously contributed to this discussion

[drodarie]

If I understand you correctly, your suggestion is not quite what I had in mind.
Personally, I wish to use this feature to get the latest commit on the specified branch that is either a successful commit, or the latest skip ci commit that follows a successful commit. Hence, if you have more than one skip ci commit, take the latest.
So I am not sure about your last point cases:

• If the CI is broken due to a commit, wouldn't it be considered as a failed commit? or at least as not a successful one?
• The skip ci commit due to release is exactly why I need this option. In our case, the release process updates the NX projects' CHANGELOGs automatically (making a skip ci commit). I do not want these changes to "pollute" the following nx affected commands.

Let me know if my explanations were clear or if I oversaw a potential issue with this use case.

[yann510]

Great points, @JamesHenry . You're right, just grabbing the latest [skip ci] commit is risky.

The scenario you described with a failed build getting sandwiched between a success and a release commit makes it clear why we need to check sequentially. Your approach avoids that problem perfectly.

This logic looks solid to me.