I have a process which has the following steps:
- Changes to git repository on bitbucket.
- Teamcity pulls changes, performs Maven build, then uploads .war file to JFrog
- Teamcity tells Octopus Deploy to create release and deploy.
- Step 1 in Octopus Deploy is it downloads the artifact from JFrog to the local file system.
- Step 2 in Octopus Deploy is a PS script that is detailed here, which performs an FTP upload of file to Azure.
- Azure takes the ROOT.war file, unpacks it, then turns the app on.
The version of my application is on 1.3.0-SNAPSHOT. I’ve made changes to the app without altering the version.
I’ve attempted to make some noticeable changes, such as a tag at the bottom of a home page (jsp), and then look for it.
When I look for evidence of this change in various places, it looks like OD is the point of failure.
The method I used to gather evidence supporting that claim was to download the war file from various locations, unpack it and inspect the home.jsp file, and look for the added line.
- From JFrog, the war file did contain the added line.
- From the OD server local disk, the war file did not contain the added line.
- From the ROOT.war file on Azure, the war file did not contain the added line.
I’m not sure if Octopus Deploy is using a cached version of the war file from somewhere, or what is happening. Somehow it’s getting an old war file, from somewhere, and uploading that to Azure.
What’s odd about this behavior is that the application runs fine, it just doesn’t contain updates to the application. What I’m about to try is some mindless version bumping to the application to see if that solves the problem, but I’d like to at least understand where Octopus Deploy is getting this war file from, because it’s not JFrog (there isn’t even an old copy of the 1.3.0-SNAPSHOT build there), and it’s not TC (same), and it’s not being built (the time it takes to build it would be very noticeable, and I don’t know where it’d get source to build it anyway).