Deployed snap doesn't reflect prime

I’m in development and have a 16.04 server setup to build and deploy a snap I’m building.

I’m using lxd for the build.

The problem I’m having is that the build process generates a war file but the wrong version of the war is deployed.

If I look at the war in the staging or prime directories the wars content is correct.
The .snap file has the correct date and time but when I deploy it for the 2nd/3rd… time its not deploying the updated version of the war. Instead I appear to get the previous version of the war.

The only way to resolve the issue is to completely uninstall all versions of the snap and then re-install.

So it appears that the actual .snap file is correct but somehow the upgrade process is broken.

So essentially my process has been

snapcraft cleanbuild auditor-webapp    # this is the part that contains/builds the war
snapcraft

snap install l --devmode auditor.snap

snapcraft cleanbuild auditor-webapp
snapcraft

snap install l --devmode auditor.snap


snapcraft cleanbuild auditor-webapp
snapcraft

snap install --devmode auditor.snap

– at this point the war in the x3 directory is identical to the version from the x2 directory.

If I now perform

snap remove auditor
snap install --devmode auditor.snap

I now have the correct war file deployed despite deploying from the same .snap.

snap --version
snap 2.32.5
snapd 2.32.5
series 16
ubuntu 16.04
kernel 4.4.0-122-generic

What’s the extra l?

Here you’re building a clean snap in a container and then overwriting that with a snap built on your host. You don’t state that you do a snapcraft clean anywhere so your locally-built snap (not in a container) will never be updated with new code from your project, because it thinks it’s already pulled the code.

The extra l was just a typo when creating the forum post :slight_smile:

I’m missed the fact that I’m using: export SNAPCRAFT_BUILD_ENVIRONMENT=lxd

My understanding is that this uses a container but builds to the local directory.

It was also my first thought that I had screwed up the build process but that argument doesn’t appear to hold up because:

if I do

snap remove auditor

then

snap install auditor.snap

I get the correct code.

If the snap wasn’t being built correctly then the remove/install should still leave me with the old code.

So I’m pretty sure this isn’t a build issue. It appears to be a problem with the install step. I’ve done a diff of the v1 and v2 directories (/var/snap/auditor/vxxx) and the two directories are identical.

Is there anyway to debug what is happening during the install phase?

Is there any requirements about the version no.s in the snap? I don’t increment my version no. in the snap between builds so I’ve been wondering if the install ignores the content of the snap if it finds the same snapcraft.xml version no.?

You still need to snapcraft clean if you want it to pick-up changes the same way you would if you were building on your host. So my comment is still the same that if you aren’t cleaning your build environment your updated code will never be pulled during build.

However, you state that completely removing the snap and installing without building an additional version beyond the one that failed to work when installed over the top does fix it. Is your war file unpacked at runtime? Does your application check the existence of that unpacked tree and not overwrite it if it exists? (Removing the snap will kill any writable directories so will remove any unpacked data, which might lead to removing the snap “fixing it” if the application refuses to overwrite the data)

I don’t need to do a full clean as only the webapp has changed and I clean that via:

snapcraft cleanbuild auditor-webapp

The war file is being unpacked as evident by the ‘diff’ and the fact I’ve done a direct examination of the webapp directory.

I’m not certain I understand the statements about my app overwriting data as I don’t think this is relevant.
Essentially the diff of the x1 and x2 directories shows that they are identical.
This implies that the two war files are identical.
So it doesn’t matter if my app won’t over-write the directories (to unpack the war) as the root problem is the war in x2 is still the old war.
Writing of the new war is clearly the job of the snap install so my applications action or lack thereof has no impact in this case.

that doesn’t do what you think it does. cleanbuild does not clean your build, but builds in a clean environment. Your local tree is unmodified, and not cleaned.

seems you mixed up snapcraft clean auditor-webapp with snapcraft cleanbuild ... that will indeed get you confusing results :slight_smile:

sorry, the build is correct just screwed up my post to this forum my build script is;

set -x
export SNAPCRAFT_CONTAINER_BUILDS=1
#snapcraft refresh
sudo service mysql stop
sudo snap stop auditor
sudo snapcraft clean auditor-webapp
sudo snapcraft
sudo snap install --devmode auditor_0.2_amd64.snap
sudo service mysql start
sudo snap start auditor

As you can see I’m correctly using ‘clean’ rather than cleanbuild.

However this is a red herring. I don’t believe the build is the problem.

If I do a snap remove auditor and then do a snap install xxxx.snap then everything works as expected.

If the problem was a build issue then a new install of the snap would still end up with the old system installed, this is not the case.

So I’m back to why the install appears to fail.

How can I debug this further?