ottr 0.1.0 causes publichealth to not build. This looks a lot like #3216 and #3263, however moving it up no longer works

[felder]

Step 18/40 : RUN /tmp/install.R && rm -rf /tmp/downloaded_packages
 ---> Running in 901e17999cf7
Downloading GitHub repo ucbds-infra/ottr@0.1.0

* checking for file ‘/tmp/remotes629d8df4b/ucbds-infra-ottr-02ccf00/DESCRIPTION’ ... OK
* preparing ‘ottr’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
Omitted ‘LazyData’ from DESCRIPTION
* building ‘ottr_0.1.0.tar.gz’

Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)

* installing *source* package ‘ottr’ ...
** using staged installation
** R
** byte-compile and prepare package for lazy loading

** help
*** installing help indices
** building package indices

** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location

** testing if installed package keeps a record of temporary installation path
* DONE (ottr)

Error in `action()`:
! `class` is absent but must be supplied.
Backtrace:
     ▆
  1. ├─base `<fn>`("/tmp/install.R", print.eval = FALSE)
  2. │ ├─base::withVisible(eval(ei, envir))
  3. │ └─base::eval(ei, envir)
  4. │   └─base::eval(ei, envir)
  5. └─devtools::install_github(...) at /tmp/install.R:6:0
  6.   └─rlang `<fn>`() at /tmp/install.R:6:0
  7.     └─rlang:::check_dots(env, error, action, call)
  8.       └─rlang:::action_dots(...)
  9.         ├─base try_dots(...)
 10.         └─rlang action(...)
 11.           └─rlang:::validate_signal_args(.subclass)
 12.             └─rlang::check_required(class, call = env)
 13.               └─rlang::abort(msg, call = call)
Removing intermediate container 901e17999cf7
The command '/bin/sh -c /tmp/install.R && rm -rf /tmp/downloaded_packages' returned a non-zero code: 1Traceback (most recent call last):
  File "/root/repo/venv/bin/hubploy", line 8, in <module>
    sys.exit(main())
  File "/root/repo/venv/lib/python3.7/site-packages/hubploy/__main__.py", line 122, in main
    image.build(not args.no_cache)
  File "/root/repo/venv/lib/python3.7/site-packages/hubploy/config.py", line 160, in build
    self.r2d.build()
  File "/root/repo/venv/lib/python3.7/site-packages/repo2docker/app.py", line 812, in build
    raise BuildError(l["error"])
repo2docker.engine.BuildError: The command '/bin/sh -c /tmp/install.R && rm -rf /tmp/downloaded_packages' returned a non-zero code: 1

Exited with code exit status 1

CircleCI received exit code 1

[felder]

https://app.circleci.com/pipelines/github/berkeley-dsep-infra/datahub/1204/workflows/56e7056e-6f28-4e2c-b46e-b255d4857bf8/jobs/10389/parallel-runs/0/steps/0-108

[felder]

I think it highly likely that other images with ottr in them will also not build.

I don't know if publichealth using 0.1.0 vs 1.1.1 matters. I suspect not.

[felder]

See issue #3216 and #3263

Note that the same fix described there was applied here. At the time it worked. Now it does not. I attempted to move the installation as far up as I believe I can. Still no good.

[balajialg]

@chrispyles Would it be possible for you to take a look at this issue and offer potential recommendations? One of the corrective actions @felder and team are thinking of is to upgrade ottr to the 1.1.4 version. Do you see any potential risk with this upgrade based on other otter deployments? Would appreciate your support here.

[balajialg]

Response from @cdbeon (Public Health GSI) regarding the proposal to upgrade ottr version: We do have a lab/homework that's to be released within the next 24 hours; anytime on Wednesday onwards should be alright. However, I'm concerned that the update to 1.1.4 would affect the students' ability to run the test cases. We're still using 0.1.0, and our current assignments are written for this specific version. To my current knowledge, updating ottr to >1.0.0, would result in an error for all of the students' test cases where the tests don't recognize the global variables (might have to do with how the tests are defined, forgive me as it's been a while since I saw the test configurations for the newer versions of ottr). We've had some cases where a few students' servers were spontaneously upgraded to 1.1.0, but the fix so far was to just downgrade the server back to 0.1.0. We could potentially find a workaround to update all the upcoming (and previous) test cases in PH 142 to the newest version if need be. I've CC'ed Kelsey (current head GSI of residential PH 142) and Mi-suk (professor), as I think they should be in the loop about this as well.

[felder]

I think this is fixed for right now.