I'm struggling to get GIT deploy working on an existing Azure web app. I did the complete same setup for another web app which is being used as a QA environment. The deploy to QA is an automated deploy for all commits on the master branch, and the commit to production is a manual deployment step and is the step after the QA deploy step.
I configured the deploy server (bitbucket pipelines using image microsoft/dotnet:sdk) and i'm doing these commands after the server pulled the sources to deploy:
The placeholders starting with $ signs are replaced by the deploy system for their real values set in a variables section.
I'm getting this exception:
! [remote rejected] master -> master (shallow update not allowed)
I solved this by googling around and applying a fix found on a forum somewhere:
Unfortunately this only changed the error message, because it changed to:
! [remote rejected] master -> master (unable to migrate objects to permanent storage)
I'm puzzled because again, I did completely the same thing for another azure webapp, of course the variables values are different but the steps and commands are the same. No complaints from kudu or git comming from the other environment. Also I doubt the shallow update exception is really what's wrong because the QA environment does not have the receive.shallowUpdate setting set.
I activated some trace logging regarding GIT and I found out that the git push command only results in a http POST of 4 bytes for the production environment, and 11165 for the QA environment. It seems git push is malfunctioning for some reason?
I was able to reproduce the same behaviour on my local pc, by replicating the commands the pipeline does during it's build setup steps and appending my own steps.
Does anyone have an idea where I should look next to get this fixed?
Hi Andreas! Looks like the error you're getting is caused by Git, and not by the Pipelines. I've searched for the error "
unable to migrate objects to permanent storage" and this is the explanation:
receive-pack: quarantine objects until
When a client pushes objects to us,
index-packchecks the objects themselves and then installs them into place.
If we then reject the push due to a
pre-receivehook, we cannot just delete the packfile; other processes may be depending on it. We have to do a normal reachability check at this point via
But such objects may hang around for weeks due to the
gc.pruneExpiregrace period. And worse, during that time they may be exploded from the pack into inefficient loose objects.
Instead, this patch teaches
receive-packto put the new objects into a "quarantine" temporary directory.
We make these objects available to the connectivity check and to the
pre-receivehook, and then install them into place only if it is successful (and otherwise remove them as tempfiles).
Presumably when it compresses objects it puts them somewhere temporarily, then in a separate action tries to move them to their permanent location. Moving them means copying them from the temporary location to the permanent location, then either deleting them from the temporary location or leaving them to be removed by other processing, possibly at another time.
The failure looks like a lack of permission (or disk space) to write to the remote location.
What git version are you using on the Server side? A git 2.10 would likely make that error disappear.
Hope that helps!
Thanks for your help. I found that explanation too, but don't really understand how this would be applicable. The destination store has enough space left, and should not have permission issues. The destination is an Azure Webapp using the Kudu toolset which also provides a way to connect and deploy via GIT. For testing i created an environment from scratch to be sure every setting was set to the default value.
The GIT version is 2.14.1.windows.1
I've had this issue for a few months - also only when running via pipelines (I can run the identical command fine from my machine). Annoying because I have to manually swap remotes and make the git push to Azure from my local dev machine after CI completes tests - not a great CI workflow.
Its worth adding this related link - https://stackoverflow.com/questions/42214667/what-does-git-mean-by-unable-to-migrate-objects-to-permanent-storage
My very rough guess is that its linux user permission related, but since I dont think we can sudo in pipelines it would be great if someone from the pipelines team could have a look into this! @Ana Retamal ?
If anyone finds a solution, please post it here :)
Sorry @Nicholas Major, I moved to another solution & platform. (Zip deploy to kudu using bamboo). Zip deploy will probably also work with pipelines but during the process of finding an alternative we also decided to use MSI authentication to connect to kudu which was already setup for our bamboo server.
I found that Bitbucket by default uses shallowed version of your git repository (probably because of performance). So there are different options, you can change your Azure (Kudu) settings to accept shallowed version or you can tell bitbucket to use full repository clone, for example:
On October 21st, 2020 we hosted a webinar titled, Step Up You DevOps Game with 4 Key Integrations for Jira and Bitbucket. We had a great showing and high engagement, but that meant th...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events