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

Inconsistency of checks? #32

Closed
schneiderpy opened this issue Jun 17, 2022 · 11 comments
Closed

Inconsistency of checks? #32

schneiderpy opened this issue Jun 17, 2022 · 11 comments

Comments

@schneiderpy
Copy link

I am stuck with a "failed check".

Checking my package concstats with pkgcheck on my local machine a came across the following issue:
In the summary popped up a failed check due to .. continuous integration, however, I have github actions for rmd check and (now) for pkgcheck
On github the bot (of pkgcheck?) the continuous integration check passed, however, it popped up a failed check for .. "Function names are duplicated in other packages"? I don't know where to look at or what function names are duplicated (I cannot check thousands of packages). This failed check does not appear on the local check (console).

@mpadge
Copy link
Member

mpadge commented Jun 17, 2022

Oh yes, another very good question! @assignUser You may well have better suggestions than me, so please chime in. The meta-problem is #30, acknowledging that we need to restructure the documentation here. This issue indicates a clear need to explain the process for understanding failed checks. The action generates full information, but can't put it all directly on the workflow output. It nevertheless creates an "artefact" with all the information you need. To see it you need to:

  1. Go to the GitHub actions page with the failed check
  2. Look at the artefacts at the bottom and download the "results":

image

  1. Extract those results and open the HTML file locally. That has lots of fold-out sections. The one you want to know about looks like this:

image


Alternatively, just run the checks locally as checks <- pkgcheck(path), and then run checks_to_markdown(checks) to automatically open the full report in your browser, as explained in the main README. Continuous Integration doesn't seem to be any issue, as those GitHub actions checks don't fail there.

I'll keep this issue open until we've clearly documented this general workflow.

@assignUser
Copy link
Collaborator

assignUser commented Jun 17, 2022

@mpadge maybe we should switch summary-only's default to false? That way the issue should contain everything except the network...

@mpadge
Copy link
Member

mpadge commented Jun 17, 2022

@mpadge maybe we should switch summary-only's default to false? That way the issue should contain everything except the network...

I've tried that, but it's not really intelligible that way - it's generally hundreds of lines of guff with very ilttle visual structure. Would it be possible to put a simple note in the workflow telling people to download the artefacts for details of failures?

@assignUser
Copy link
Collaborator

In my testing it had the same html summary fold out thingies... so it was a bit longer but not fa full CVS-receipt... let me check

@assignUser
Copy link
Collaborator

@mpadge like this: assignUser/octolog#14 this is 3 months old though so maybe something changed with the output?

@mpadge
Copy link
Member

mpadge commented Jun 17, 2022

Oh yeah, sorry, my bad there. Yes, we definitely need summary_only: false. @schneiderpy you just need to follow this example from the docs and you'll get the full explanations of your failing checks in the issue:

jobs: 
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: ropensci-review-tools/pkgcheck-action@main
        with:
          summary-only: false

Forget what i said above about artefacts; you don't need to worry about that.

@schneiderpy
Copy link
Author

schneiderpy commented Jun 18, 2022 via email

@schneiderpy
Copy link
Author

schneiderpy commented Jul 11, 2022 via email

@mpadge
Copy link
Member

mpadge commented Jul 12, 2022

@schneiderpy I'm not really sure what your questions are in the above? Please note that GitHub issues respect all markdown formatting, so you should please use that. In other words, please run checks_to_markdown(), and paste the markdown-formatted result directly in any issue comments.

The inconsistencies between standardised checks via pkgcheck-action and your local checks could be due to any number of things. If you're not seeing local CI checks, that likely suggests that you don't have your GitHub authorization token set up properly. That's explained on the pkgcheck README.

The inconsistences between what you see directly on your console screen and the markdown-formatted versions are an unavoidably consequence of compromises necessary in trying to convey a lot of information in compact ways. The most complete version is always the markdown/html version generated by checks_to_markdown(), while the screen version will generally be only an abbreviated version of that.

Finally, regarding function names, I would suggest in your case that yes, you ought to rename a lot of them as many of the names are quite generic. A standard package-specific prefix is the generally recommended approach. This is often some abbreviated form of a full package name, although in your case the function names are generally quite short, so yes, prefixing with concstats_ would seem like a reasonable approach. Note also ropensci-review-tools/pkgcheck#144 - once that's been implemented these namespace conflicts won't necessarily be an outright fail, but again in the case of your package i would suspect that reviewers would likely suggest what I'm suggesting here regardless.

@schneiderpy
Copy link
Author

schneiderpy commented Jul 13, 2022 via email

@mpadge
Copy link
Member

mpadge commented Jul 13, 2022

Am I right that I have to do a new CRAN / Zenodo submission?

That's entirely up to you, and not related either to this issue, nor to pkgcheck-action in general, so I'm going to close this for now. Your questions seem to be more ones of general package development workflow, for which there are several good references. In particular, for potential submissions to rOpenSci, please refer to our general package development guide, as well as our statistical software guide.

@mpadge mpadge closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2022
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

3 participants