Skip to content
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

Report directory structure when comparing branches seems off #287

Open
dsager opened this issue Jan 14, 2019 · 5 comments
Open

Report directory structure when comparing branches seems off #287

dsager opened this issue Jan 14, 2019 · 5 comments

Comments

@dsager
Copy link

dsager commented Jan 14, 2019

When running rubycritic in CI mode, the report-folder seems to be weirdly nested.

After executing the following command (while on a branch called test-123):

$ rubycritic --mode-ci=develop --format=json app

I get the following directory structure:

tmp/rubycritic/
├── build_number.txt
└── compare
    ├── build_details.txt
    └── develop
        ├── compare
        │   └── test-123
        │       ├── compare
        │       │   └── report.json
        │       └── report.json
        └── report.json

I would expect the structure to be this:

tmp/rubycritic/
├── build_number.txt
└── compare
    ├── build_details.txt
    ├── develop
    │   └── report.json
    ├── test-123
    │   └── report.json
    └── report.json

Actually, when generating a HTML report, the links in the top right corner also seem to expect this structure.

Version
Ruby 2.3.7
RubyCritic 3.5.2

I am happy to create a PR for this, jut wanted to confirm first if this is an actual issue. I think the problem is that Config.root is overwritten in two places during the branch comparison and not reset to its initial value: here and here.

While at it, I have two additional questions regarding the CI mode (happy to create separate issues if preferred):

  • The help (and also the readme) states that the CI mode will be faster. This currently seems to not be the case, as it runs a full analysis of both branches, and then looks at the diff. So it's about twice as slow as the normal run. Maybe I am doing something wrong (see command above)?
  • Wouldn't it make more sense to include the information stored in build_details.txt in the json output, so that it can be easily parsed?
@GeoffTidey
Copy link
Contributor

I can confirm (one year on) that I'm seeing the same issue as @dsager

We're using ruby 2.7 & rubycritic 4.3.1 &

rubycritic app -p $CIRCLE_ARTIFACTS/rubycritic --mode-ci -f html --no-browser

An example of an actual file on disk is:
/tmp/circleci-artifacts/rubycritic/compare/master/compare/staging/overview.html

whilst the link in the top right corner is pointing at:

/tmp/circleci-artifacts/rubycritic/compare/staging/overview.html

@denny
Copy link
Contributor

denny commented Jan 15, 2021

And another year on, this confused me briefly last week 🙂

ETA: By the way, this isn't unique to CI mode - I didn't have CI mode configured, I just had branch: main at the top-level of my config file.

@etagwerker
Copy link
Collaborator

@dsager I think it makes sense to restructure the directories the way you would expect them. If you submit a PR I'd be happy to review it.

The help (and also the readme) states that the CI mode will be faster. This currently seems to not be the case, as it runs a full analysis of both branches, and then looks at the diff. So it's about twice as slow as the normal run. Maybe I am doing something wrong (see command above)?

Not sure why it says that, comparing two branches will always take longer than running just one analysis. Maybe it should be corrected in the documentation?

Wouldn't it make more sense to include the information stored in build_details.txt in the json output, so that it can be easily parsed?

I think that is a good idea. 👍

@dsager
Copy link
Author

dsager commented Jan 18, 2021

Hi @etagwerker , we no longer use RubyCritic. I am afraid I lost the context for this issue over time and have to retract my offer of making a PR to fix this 😆

Not sure why it says that, comparing two branches will always take longer than running just one analysis. Maybe it should be corrected in the documentation?

Maybe I'm not thinking this through entirely, but I think running an analysis of just the affected files should work and be faster?

@denny
Copy link
Contributor

denny commented Feb 26, 2021

@GeoffTidey If you have the time and you're still interested, could you check whether my PR merged above has fixed this for you? Thanks 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants