mutating affectedFiles on prepush hook

[tomdavidson]

My workflows squash merge so individual commits in a working branch do not really matter other than for the review. Formatting and complex linting on every commit is troublesome, especially when its expected to fail. The objective of my prepush githook tasks is to avoid waiting for 5-20min to learn of a simple defect via ci runner and to avoid formatting noise but to avoid additional obstacles of just failing when it could be auto resolved.

with a prepush hook such as

#!/bin/sh
./node_modules/@moonrepo/cli/moon run :lint-fix :format --affected

I will end up with git in a dirty state. Maybe dprint will be fast enough to do this on a precommit but prettier sure aint and some eslint rules are not.

Withe the awesome affectedFiles being appended to the args list, I should b able to have a script capture a list of the files to feed into additional git cmds. Unfortunately, Ill have to identify which args are files. I understand the token for the affectedFiles was not a feasible direction at this time. What about MOON_AFFECTED_FILES env var?

I also could just use moon query or git diff CHANGED_FILES=$(git diff ....) but then I do not have the workspace context and I need eslint to run in the workspace scope not a global scope.

Do you have a suggestion?

[milesj]

@tomdavidson Before I dig further, maybe I missed it, but what exactly are you trying to solve?

So you get into a dirty state, are you trying to use this file list to git add them? If so, one option would be to read the .moon/cache/runReport.json (or ciReport.json) file and parse context.touchedFiles.

[tomdavidson]

context.touchedFiles sounds like just what I need, but I dont have a runReport.json or a ciReport.json. Would context.touchedFiles be the same as the passed affected files with the filtering?

Thoughts about adding a MOON_AFFECTEDFILES var to the task env?

The new affectedFiles feature works perfectly, as is, for running unit tests on a prepush hook.

[milesj]

@tomdavidson The touchedFiles will be all touched files across the repo, not just the ones for an individual task, but is a good enough list to determine like git add.

For the env var, I'm curious how you'd access it? It'll be scoped to the child process and wouldn't be accessible from the hook file itself.

You'll need to pass --report to generate the runReport.json file. In CI this is automatically, but is called ciReport.json.

[tomdavidson]

Ahh thanks for --report

As for env var, I think it could need to be consistent with envFile or just like the other MOON_ENVVARS

Im going to end up running a script, parsing args to get the list of files, processing each one, writting it back with the captured file name. Having the env var would get me out for the arg parsing which isnt that big of a deal but I think it could get away with something like

prepush:
  command: bash -c ' eslint $FILES && prettier $FILES && git add $FILES' # or loop and pipe if thats faster than the io
 

I think I just need to separate the args and set the var in script and then I can do the same without any change to moon.

[milesj]

Yeah sounds good. I can add the env var real quick, let me take a look at feasibility. 👍

[tomdavidson]

I don't feel like every education has to be solve for me when there's a decent work around.

I think it really thing it just comes down to avoiding the script whether it's in yaml or external ... And I should have chewed on this one more before opening up the discussion.

I still don't understand all the nuances but I've appreciated moon's theory of use and I hope that if any of my requests are inconsistent that they are turned down or modified.

[milesj]

@tomdavidson It's all good. My goal with moon is automate/improve all workflows and the dev experience. So I'm open to any good ideas, and this is one. I threw up a PR here: #457