balena-io / balena-cli

The official balena CLI tool.
Apache License 2.0
455 stars 142 forks source link

Livepush not restarting container with Dockerfile.template #2195

Open peteretep opened 3 years ago

peteretep commented 3 years ago

I am developing python applications on Balena and am attempting to develop locally using the livepush feature. The changes I make to my code are not being livepushed.

I have created a very simple project to test. The folder layout is like this:

balenatest/
├── Dockerfile.template
└── test.py

The Dockerfile.template looks like this:

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-python:3.9
WORKDIR /usr/src/app
COPY /test.py .
CMD python test.py

The test.py file looks like this:

import logging
from time import sleep

while True:
    logging.warning("first logged message")
    # logging.warning("second logged message")
    sleep(10)

Expected Behavior

I run the project with

balena push 45b5050.local --debug

The system comes up and I see the first logged message being logged. I edit the file in VS Code to uncomment the line # logging.warning("second logged message"). I expect the system will reload and start logging the second logged message line to the console. It does not.

Actual Behavior

The system seems to see the change to the file but does not reload the container.

[Live]    Device state settled
[Logs]    [2/23/2021, 15:31:48] [main] WARNING:root:first logged message
[Debug]   Got an add filesystem event for service: main. File: test.py.b307392204ac8de2adfaccac7a4a32a7.tmp
[Debug]   Got an add filesystem event for service: main. File: test.py
[Debug]   Got an add filesystem event for service: main. File: test.py.b307392204ac8de2adfaccac7a4a32a7.tmp
[Logs]    [2/23/2021, 15:31:58] [main] WARNING:root:first logged message

If I log into the container with balena ssh main I see the original code - the change has not been applied.

peteretep commented 3 years ago

Related to / duplicate of #1949 ?

pdcastro commented 3 years ago

Thanks for reporting this issue @peteretep 👍

I have reproduced it and found that a workaround is to rename Dockerfile.template to Dockerfile, and edit the FROM line to replace the template variable with a specific device name. In my case, I was testing with an Intel NUC device, so my workaround Dockerfile ended up looking like:

Dockerfile.template renamed to Dockerfile

# FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-python:3.9
FROM balenalib/intel-nuc-debian-python:3.9
WORKDIR /usr/src/app
COPY /test.py .
CMD python test.py

I am taking the liberty of changing this issue's title a bit, to reflect this finding.

peteretep commented 3 years ago

Thank you - I did think of testing that but then forgot! That will get me up and running for now - we are developing for pi 3 at the moment. Will try tomorrow.

peteretep commented 3 years ago

This is not working for me. My Dockerfile now looks like this:

FROM balenalib/raspberrypi3-alpine-python:3.9
WORKDIR /usr/src/app
COPY /test.py .
CMD python test.py

Behaviour is the same - the container does not restart. Could it be a raspberry pi3 issue?