You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you supply a lockfile to golem::add_dockerfile_with_renv_heroku() called simply renv.lock then the second/main Dockerfile created still expects a file called renv.lock.prod which is what is automatically generated when you do not supply a lockfile. I believe the Dockerfile_base does pick up the difference though.
I think a workaround is to just rename the renv.lock to renv.lock.prod in the deploy folder. I think this issue also occurs when creating a generic dockerfile. I will look into it.
Example Dockerfile:
...
COPY renv.lock.prod renv.lock
RUN R -e 'renv::restore()'
COPY phase_*.tar.gz /app.tar.gz
RUN R -e 'remotes::install_local("/app.tar.gz",upgrade="never")'
RUN rm /app.tar.gz
...
The text was updated successfully, but these errors were encountered:
If you supply a lockfile to
golem::add_dockerfile_with_renv_heroku()
called simplyrenv.lock
then the second/main Dockerfile created still expects a file calledrenv.lock.prod
which is what is automatically generated when you do not supply a lockfile. I believe the Dockerfile_base does pick up the difference though.I think a workaround is to just rename the renv.lock to renv.lock.prod in the deploy folder. I think this issue also occurs when creating a generic dockerfile. I will look into it.
Example Dockerfile:
The text was updated successfully, but these errors were encountered: