Only lint modified files

[theoomoregbee]

I was going through the codebase to see how feasible to add this feature because we currently need it.

Suggestion

I was thinking of adding an extra param [linter]_only_changed_files: boolean (we can decide on the best name to go with).

Then checking doing a quick diff of the current branch with

FILES = git diff --diff-filter=$filter --name-only $baseBranch | grep -E $extensions

where:

• $filter: can be defaulted to ACM (added, copied and modified), more: https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-filterACDMRTUXB82308203
• $baseBranch: we can get the base branch from event.pull_request.base.ref
• $extensions: e.g .js|.ts or we use the default extension from the lint configuration

I see you already swap branch for hasFork here: https://github.com/samuelmeuli/lint-action/blob/a820202c34156c11c68a7c534178ac66e12758b9/src/git.js#L22

We just need to do the same thing with the base repository:

• check if it's a fork, if so fetch it and add it to maybe base-fork remote locally
• else if it's not a fork, we don't need to fetch
• with the above steps, we can easily infer the base remote and branch name

Don't know if this is what you want to support @samuelmeuli else I can spin up a PR for this.

@samuelmeuli wdyt?

[samuelmeuli]

It would be great to have this working. I'm just not quite sure if this will work nicely with GitHub annotations (see #1).

In any case, this would be a follow-up to #46. It might also make sense to delegate the identification of modified files to another action (e.g. file-changes-action) and use that action's output as input for the [linter]_files option.

[ozum]

This should be optional, because if a lint rule is changed, it should lint all source files again for new rules whether those files changed or not.

[theoomoregbee]

@samuelmeuli went through #1 will read on github annotation over the weekend and see if there's a possibility for getting this in.

In any case, this would be a follow-up to #46. It might also make sense to delegate the identification of modified files to another action (e.g. file-changes-action) and use that action's output as input for the [linter]_files option.

Nice fallback

[panda0603]

@theoomoregbee @samuelmeuli any progress on this issue? Thanks

[theoomoregbee]

@theoomoregbee @samuelmeuli any progress on this issue? Thanks

We had a blocker kinda as mentioned in #1 but had not gotten free time to go over GitHub annotations yet to see if there's a way around it.

Will add it to my todo list for the week now and see if I can go over it on or before the weekend.

[theoomoregbee]

Did some research regarding #1 and found a GitHub action that helps with annotation via a .json file: https://github.com/Attest/annotations-action.

They just released a new version of runner that helps with composite actions https://docs.github.com/en/actions/creating-actions/about-actions#composite-run-steps-actions

But it's not fully ready to support calling an action within another action yet (which I think is the main reason we need the composite action though lol actions/runner#646 (comment)

Here are the next steps for composite actions: actions/runner#646

When expected action within action is released, we can leverage

• file changes(conditional step, if to check for modified files or entire branch) https://github.com/trilom/file-changes-action
• Run eslint and parse errors/warnings messages to follow https://github.com/Attest/annotations-action/blob/master/annotations.json (type definition: https://github.com/Attest/annotations-action/blob/master/src/annotation.ts)

[github-actions]

A stale label has been added to this issue because it has been open 15 days with no activity. To keep this issue open, add a comment within 5 days.