-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add only_changed input to run rubocop only against changed files #103
add only_changed input to run rubocop only against changed files #103
Conversation
2aac704
to
cd3cfda
Compare
cd3cfda
to
998b37a
Compare
@javierjulio May I ping you for input? |
02f0ae4
to
c83f927
Compare
c83f927
to
2719576
Compare
Can you add a test? #103 |
@haya14busa Can you suggest how/what to test? I can think of either adding test branches and test workflows to check complete thing, or just unit testing |
@@ -70,6 +74,8 @@ runs: | |||
INPUT_TOOL_NAME: ${{ inputs.tool_name }} | |||
INPUT_USE_BUNDLER: ${{ inputs.use_bundler }} | |||
INPUT_WORKDIR: ${{ inputs.workdir }} | |||
BASE_REF: ${{ github.event.pull_request.base.sha }} | |||
HEAD_REF: ${{ github.sha }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First off all thanks for this PR, it seems like a really useful addition that could speed up our github action by a lot as using rubocop takes about 5 minutes currently to run over the whole repo.
Should this look at github.event.pull_request.base.sha
instead?
I tried out your branch in a github action workflow but the HEAD_REF commit seemed wrong and gave me the following error: fatal: Invalid revision range
After creating my own branch based on this but with the change to the HEAD_REF sha the action succeeded
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean using github.event.pull_request.head.sha
for HEAD_REF
?
The idea of this change is to give to rubocop only files introduced in the PR branch, but we don't want to also give to rubocop files that changed on the base branch especially if it diverged a lot.
This could be resolved in different ways, but in current implementation the idea is to also fetch bare minimum to not slowdown by fetching, so usage of actions/checkout
with default depth: 1
is assumed.
Also github.sha
is pointing at automatically created merge commit of base into head (docs), while github.event.pull_request.head.sha
points at the PR branch head.
If we would have all commits available it would be simpler to do diff base...head
(note three dots) where head can be both merge commit or the tip of the branch, but if we fetch only two tips of the branches, diff base...head
is not possible, as not all needed commits are available.
Otherwise diff base..merge-head
should give much smaller diff then diff base..head
.
So most probable cause of fatal: Invalid revision range
is because your workflow either doesn't fetch the tip of the base branch or fetches not the automatically created merge head (default using actions/checkout).
I think we can add a job (or workflow) with only_changed=true and add new test files under test dir. We can at least check the behavior with this pr. |
@@ -85,9 +88,41 @@ else | |||
BUNDLE_EXEC="bundle exec " | |||
fi | |||
|
|||
if [ "${INPUT_ONLY_CHANGED}" = "true" ]; then | |||
echo '::group:: Getting changed files list' | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about running `git fetch --depth 1 origin "${BASE_REF}" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good idea, compared to adding a step to do it manually. Only concern is if remote is named differently or if checkout is very custom, so the command breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing it after checking commit availability should be the good way to make it simple by default and solvable if default doesn't work: eb0eda0
Ideally, it would be great if we can use the existing solution like https://github.com/tj-actions/changed-files for getting changed files so that we can reuse the similar solution for other reviewdog actions. But we use robocop specific command ( |
eb0eda0
to
5ea6c6e
Compare
Switch to bash for process substitution and working with arrays. Ignore if there are more than 100. Protecting from possibly hitting the command line length limit, it can be much higher and can be calculated or also extracted as one more input if needed. The effect from limiting number of files processed by rubocop is also smaller. Fix ci workflow to fetch all commits for pr branch plus head commit of base branch to be able to find changed files. Co-authored-by: Oliver Günther <mail@oliverguenther.de>
Any update on this? Would love to see this merged. |
@v-kumar I did an unsuccessful attempt and afterwards came up with a working way to test this, but didn't yet have time. The idea is to test by running the script while mocking binaries by manipulating |
5ea6c6e
to
705dbf7
Compare
13a7ab4
to
4e840d4
Compare
@haya14busa I added tests of script.sh without using any frameworks |
- name: Check when there are too many relevant files | ||
run: | | ||
git checkout ${{ github.sha }} | ||
touch a{00..100}.rb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create 101 (more than 100) files here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The range is inclusive, so 101 files are generated, I can change to {01..101}
if it will be clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accidentally tested that with exactly 100 it passes file names to rubocop: https://github.com/reviewdog/action-rubocop/actions/runs/9913233268/job/27389778004
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok.
I'm a bit confused, but why does the test result shows " No relevant files for rubocop, skipping"?
https://github.com/reviewdog/action-rubocop/actions/runs/9913690348/job/27391225472
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great that you spotted it, I didn't notice that change from ruby to bash script for rubocop mock was producing files prefixed with ./
. I reverted to ruby script for simplicity and hardened the test by explicitly validating that reviewdog mock was or was not called.
4e840d4
to
2f1682e
Compare
2f1682e
to
baffa02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution! 💯
Hi, @toy! We merged your PR to reviewdog! 🐶 We just invited you to join the @reviewdog organization on GitHub. Thanks again! |
🚀 [bumpr] Bumped! New version:v2.17.0 Changes:v2.16.0...v2.17.0 |
${INPUT_RUBOCOP_FLAGS} \ | ||
--require ${GITHUB_ACTION_PATH}/rdjson_formatter/rdjson_formatter.rb \ | ||
--format RdjsonFormatter \ | ||
--fail-level error \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@toy
Did you want to intentionally change(set) fail-level
?
I think it seems a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kehra It was intentional, due to turning on pipefail, which in turn is needed for pipes in getting the list of changed files.
Before this commit the exit code of rubocop … | reviewdog …
was the exit code of reviewdog. But with pipefail and without changing fail-level
, any rubocop violation would make the script have an error exit code, which will be confusing, as both violations will be reported and the action will fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kehra #120 looks good, it allows to "shoot in the foot" by changing formatter, but I think it is better to restrict less.
I'm still wondering about your CI - any violations of any level will create either annotation or comment to PR, so the rubocop outcome will be failing, but not the rubocop action itself, am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@toy
Hmm.
I might be wrong, so I'll investigate this again 💦
Sorry for bothering you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, I'm just trying to understand if there is some case that allows action to not report violations. Please reply with your findings
Since PR reviewdog#103 introduced the default --fail-level flag, the severity level has become unchangeable due to this modification. Ideally, this flag (and others) should be overridable, but the RuboCop command prioritizes the flags that are specified last. This commit moves the user-specified flags to the end of the hard-coded flags, allowing them to be overridden. Signed-off-by: moznion <moznion@mail.moznion.net>
Since PR #103 introduced the default --fail-level flag, the severity level has become unchangeable due to this modification. Ideally, this flag (and others) should be overridable, but the RuboCop command prioritizes the flags that are specified last. This commit moves the user-specified flags to the end of the hard-coded flags, allowing them to be overridden. Signed-off-by: moznion <moznion@mail.moznion.net>
Add an input to limit running rubocop only against files changed in the PR.
Had to switch to bash for process substitution and working with arrays.
Ignore if there are more than 100 changed files. Main reason is to protect from possibly hitting the command line length limit. In reality the command line length limit most probably (depends on OS) allows much higher number of files and if needed can be calculated or provided as one more input.
Fix ci workflow to fetch all commits for pr branch plus head commit of base branch to be able to find changed files.
Will conflict with #102, I will update whichever is not merged first