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

Failing incoming CRAN checks #50

Open
Robinlovelace opened this issue Apr 27, 2024 · 4 comments
Open

Failing incoming CRAN checks #50

Robinlovelace opened this issue Apr 27, 2024 · 4 comments
Labels
help wanted Extra attention is needed

Comments

@Robinlovelace
Copy link
Member

I spoke too soon in #49, it bounced from CRAN, with the following message:

package calendar_0.1.0.tar.gz does not pass the incoming checks automatically, please see the following pre-tests:
Windows: https://win-builder.r-project.org/incoming_pretest/calendar_0.1.0_20240427_153111/Windows/00check.log
Status: 1 ERROR
Debian: https://win-builder.r-project.org/incoming_pretest/calendar_0.1.0_20240427_153111/Debian/00check.log
Status: 1 ERROR

Last released version's CRAN status: OK: 12
See: https://cran.r-project.org/web/checks/check_results_calendar.html

CRAN Web: https://cran.r-project.org/package=calendar

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the R-package-devel mailing list:
https://stat.ethz.ch/mailman/listinfo/r-package-devel
If you are fairly certain the rejection is a false positive, please reply-all to this message and explain.

More details are given in the directory:
https://win-builder.r-project.org/incoming_pretest/calendar_0.1.0_20240427_153111/
The files will be removed after roughly 7 days.

*** Strong rev. depends ***: stRoke

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
Maintainer: 'Robin Lovelace <rob00x@gmail.com>'

Flavor: r-devel-windows-x86_64
Check: tests, Result: ERROR
Running 'testthat.R'
Running the tests in 'tests/testthat.R' failed.
Complete output:
> library(testthat)
> library(calendar)
>
> test_check("calendar")
[ FAIL 1 | WARN 1 | SKIP 0 | PASS 11 ]

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test-ic-extract.R:4:3'): ic_extract works ─────────────────────────
ic_extract(ical_example, "DTSTART") not equal to as.POSIXct("2018-08-09 16:00:00 BST").
1/1 mismatches
[1] 2018-08-09 18:00:00 - 2018-08-09 16:00:00 == 2 hours

[ FAIL 1 | WARN 1 | SKIP 0 | PASS 11 ]
Error: Test failures
Execution halted

Flavor: r-devel-linux-x86_64-debian-gcc
Check: tests, Result: ERROR
Running 'testthat.R' [1s/1s]
Running the tests in 'tests/testthat.R' failed.
Complete output:
> library(testthat)
> library(calendar)
>
> test_check("calendar")
[ FAIL 1 | WARN 1 | SKIP 0 | PASS 11 ]

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test-ic-extract.R:4:3'): ic_extract works ─────────────────────────
ic_extract(ical_example, "DTSTART") not equal to as.POSIXct("2018-08-09 16:00:00 BST").
1/1 mismatches
[1] 2018-08-09 18:00:00 - 2018-08-09 16:00:00 == 2 hours

[ FAIL 1 | WARN 1 | SKIP 0 | PASS 11 ]
Error: Test failures
Execution halted

Anyone know how to fix this? I'm a bit bamboozled as the tests pass locally and on actions as far as I can tell? Any support very, very welcome 🙏

@Robinlovelace Robinlovelace added the help wanted Extra attention is needed label Apr 27, 2024
@silverfoxdoc
Copy link
Contributor

silverfoxdoc commented Apr 27, 2024

I'm thinking that's because of my pull request. Should have done the testthat scripts before submitting pull request but not got any real experience using testthat.

DTSTART:20180809T160000Z in ical_example is in zulu time; therefore given August is BST time zone and we're converting the zulu time zone to local it would actually be UTC+1 and so 17:00

So I think we should be testing against as.POSIXct("2018-08-09 17:00:00 BST") rather than 16:00 now that we're converting zulu times to local times

@Robinlovelace
Copy link
Member Author

Yes makes sense @silverfoxdoc.. Quick fix? Long time since I looked at the code as you can tell!

@Robinlovelace
Copy link
Member Author

Fix could be here:

test_that("ic_extract works", {
expect_equal(ic_extract(ical_example, "DTSTART"),
as.POSIXct("2018-08-09 16:00:00 BST"))
})

@Robinlovelace
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants