failed balena deploy

Hi!

I am trying to update an app I have already deployed.

after the end of the deploy (and the appearance on the unicorn :grin:) i get a release uuid, but if i compare it to the uuid after the command balena app < my-app > the commit is different from the first uuid, and the application doesn’t update.

I am using the balena-cli version 12.2.2 and openBalena

the app is a multicontainer one for rpi3

any hints? Thanks!

Hey,

When you say the application doesn’t update, do you mean the value in the CLI output, or the device running the app, or both?

Could you also share the commands you’re running to do the build/release?

thanks

Hi!

both the cli output of the balena app and the device doesn’t update.

balena build --deviceType raspberrypi3 --arch armv7hf --emulated --dockerfile Dockerfile --emulated

This is the command to build each docker image, then:

    balena deploy myApp

with a docker-compose file in the myApp’s directory

The result of this call:

 curl -X GET \
"https://api.mydomain.org/v5/release?\$filter=belongs_to__application%20eq%20<AppID>" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <myToken>"  --cacert ~/path/ca.crt 

(I have removed my domain with “mydomain”, the AppID and my token for security reason)

Gives as output different images (I have changed some versions) from the one i put in the docker-compose

Thanks, but is there a reason for the split in your build/deploy steps? Could you try balena deploy myApp --logs --source . --emulated and see what that does?

balena deploy r3-generic --logs --source . --emulated --verbose --debug

Output:

[Debug]   Parsing input...
(node:2307) ExperimentalWarning: The fs.promises API is experimental
[Debug]   Loading project...
[Debug]   Resolving project...
[Debug]   docker-compose.yml file found at "/Users/matteo/Desktop/path/r3-generic"
[Debug]   Creating project...
[Info]    Everything is up to date (use --build to force a rebuild)
[Info]    Creating release...
[Debug]   Tagging images...
[Debug]   Authorizing push...
[Debug]   Requesting access to previously pushed image repo (v2/uuid)
[Debug]   Requesting access to previously pushed image repo (v2/uuid)
[Debug]   Requesting access to previously pushed image repo (v2/uuid)
[Debug]   Requesting access to previously pushed image repo (v2/uuid)
[Info]    Pushing images to registry...
[Debug]   Saving image registry.domain.org/v2/uuid
[Debug]   Saving image registry.domain.org/v2/uuid
[Debug]   Saving image registry.domain.org/v2/uuid
[Debug]   Saving image registry.domain.org/v2/uuid
[Debug]   Untagging images...
[Info]    Saving release...
[Success] Deploy succeeded!
[Success] Release: aeab7ee68aa5b6a0f8a1d4eff37e2d8b

and then

balena app r3-generic

Output:

== R3 GENERIC
ID:          47
DEVICE TYPE: raspberrypi3
SLUG:        r3-generic
COMMIT:      c82c8375e8072eb0223df7553890095a

it seems like this app won’t update

balena devices --application r3-generic

Hi, can you check the status of the devices inside this application?

It’s a fleet of devices so I am parsing the output

devices --application r3-generic

ID  UUID    DEVICE NAME              DEVICE TYPE     APPLICATION NAME STATUS IS ONLINE SUPERVISOR VERSION OS VERSION           DASHBOARD URL

73 uuid 73 [name]  raspberrypi3    r3-generic       Idle   true      10.2.2             balenaOS 2.43.0+rev1 https://dashboard.domain.org/devices/uuid /summary

another command

balena device uuid

output:

== 73 [name]
ID:                 73
DEVICE TYPE:        raspberrypi3
STATUS:
IS ONLINE:          true
IP ADDRESS:         ip
APPLICATION NAME:   r3-generic
UUID:               uuid
COMMIT:             c82c8375e8072eb0223df7553890095a
SUPERVISOR VERSION: 10.2.2
OS VERSION:         balenaOS 2.43.0+rev1
DASHBOARD URL:      https://dashboard.domain.org/devices/uuid/summary

Can you ssh into the device and see the supervisor logs with journalctl -f -a -u resin-supervisor?

journalctl -f -a -u resin-supervisor

output:

-- Logs begin at Thu 2019-08-08 09:59:55 UTC. --
Sep 24 12:22:07 f55c052 resin-supervisor[1665]: [debug]   Container log timestamp flush complete
Sep 24 12:22:18 f55c052 resin-supervisor[1665]: [api]     GET /v1/healthy 200 - 16.939 ms
Sep 24 12:23:18 f55c052 resin-supervisor[1665]: [error]   LogBackend: server responded with status code: 504
Sep 24 12:27:19 f55c052 resin-supervisor[1665]: [api]     GET /v1/healthy 200 - 14.931 ms
Sep 24 12:28:20 f55c052 resin-supervisor[1665]: [error]   LogBackend: server responded with status code: 504
Sep 24 12:30:47 f55c052 resin-supervisor[1665]: [error]   LogBackend: server responded with status code: 504
Sep 24 12:32:07 f55c052 resin-supervisor[1665]: [debug]   Attempting container log timestamp flush...
Sep 24 12:32:07 f55c052 resin-supervisor[1665]: [debug]   Container log timestamp flush complete
Sep 24 12:32:15 f55c052 resin-supervisor[1665]: [error]   LogBackend: server responded with status code: 504
Sep 24 12:32:20 f55c052 resin-supervisor[1665]: [api]     GET /v1/healthy 200 - 8.782 ms
Sep 24 12:33:25 f55c052 resin-supervisor[1665]: [error]   LogBackend: server responded with status code: 504

What’s the result when calling api directly?

curl -X GET "https://api.{domain}/v5/application(<app_id>)" -h "Authorization: Bearer {API token}"

output:

{"d":[{"created_at":"2020-08-04T08:11:55.477Z","id":47,"actor":507,"should_track_latest_release":false,"app_name":"r3-generic","slug":"r3-generic","device_type":"raspberrypi3","VPN_host":"vpn.domain.org","VPN_port":443,"commit":"c82c8375e8072eb0223df7553890095a","depends_on__application":null,"application_type":{"__deferred":{"uri":"/resin/application_type(0)"},"__id":0},"__metadata":{"uri":"/resin/application(47)","type":""}}]}

I see that should_track_latest_release is set to false, can you run:

curl -X PATCH \
"https://api.balena-cloud.com/v5/application(<ID>)" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <AUTH_TOKEN>" \
--data '{
    "should_track_latest_release": "true"
}'

Ok, I’ve changed the flag, now I should redeploy the app or just wait?

PS: is this flag should_track_latest_release always set to false?

Redeploying should do it. should_track_latest_release is not set to false by default.

Now it works thanks!