Cache invalidated when it shouldn't have been

Product support
1

Git push problems occurred where running:

git push balena-remote my-branch:master
Returned:

Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 1.21 KiB | 0 bytes/s, done.
Total 13 (delta 11), reused 0 (delta 0)

[Error]    An error occurred: ESOCKETTIMEDOUT
[Error]    Not deploying release.

remote: error: hook declined to update refs/heads/master
To git.balena-cloud.com:me/my-application.git
 ! [remote rejected] my-branch -> master (hook declined)
error: failed to push some refs to 'me@git.balena-cloud.com:me/my-application.git'

So I tried git push -f balena-remote my-branch:master which failed with the same errors.

But after repeated attempts to push it finally worked… and invalidated my cache (I had to rebuild everything, costing 30 minutes or so).

I think that this is caused by the -f (force) flag?

If so, what was the ESOCKETTIMEDOUT error? Do I have to remedy that with a force push or is the best strategy to just repeatedly attempt to push?

3

Hi @cnr . From what I understand the ESOCKETTIMEOUT error is due to the git server and builder not being able to connect to the docker socket on the builder. I think the issues were experiencing may have been due to elevated error rate we have been seeing on our ARM Native builders.

The -f flag on git push is essentially rewriting the git history, it by itself should not cause cache invalidation, but perhaps rewriting the app history at the time when the builder and/or API are having issues caused the cache to be invalidated, but its difficult to say. I’ll check with some of the backend team to see if they have any other ideas as to why it would invalidate.

But in general, if you see the ESOCKETTIMEDOUT error, I would first check https://status.balena.io/ to make sure the infrastructure is working correctly and if it is up, I would wait a few minutes or so before pushing again. You shouldn’t ever have to use the -f in these cases and I think if anything it could make things worse :confused:

4

Ok, thank you for the response.

I will avoid the -f flag in future and be more patient :slight_smile: