TC Configuration Format Version

Answered

I have been trying to reconstruct a TC server (running on docker) that was used by a group that is no longer in communications with us. Error is below. 
Now I have tried searching through the web and the host (and container) that will help me correspond the software version. I have not found software version 812 anywhere, that would explain why im running into this.
I was trying to connect to a database but this error pops up. Can anyone help me guide my way out of this issue, please?
Thanks in Advance. Inserting a Screenshot of the error.

TeamCity configuration format version corresponds to a more recent TeamCity version: 898 while required by current software version is 812.
TeamCity cannot start as data downgrade is not supported. Please start a TeamCity version that matches the data version or restore from a backup matching the current TeamCity version.
See details at https://confluence.jetbrains.com/display/TCD10/Upgrade.
8 comments
Comment actions Permalink

The data format version of 812 was used in TeamCity 9.x. You can download the installer for it here: https://www.jetbrains.com/teamcity/download/other.html. Once you have it up and running, you can upgrade it to the latest release.

0
Comment actions Permalink

How would I change the software version to 812 in docker container. 
I have never had to upgrade or downgrade anything TC related, so kind of lost. 

0
Comment actions Permalink

Sorry, I think I may have made this confusing. In your situation, it appears you're running an old TeamCity version but your data directory is from a later release, 2019.1.x. It is typical to have the data directory in a volume outside of the container and the database in another container, so probably the container you're running is an old one that was replaced by a newer container at some point.

If this is your case, it should be possible to run an instance of jetbrains/teamcity-server on a release that matches your data directory format. You'll also need to determine the networking used to reach the database (assuming it is an external database), which is also needed in order to run TeamCity. The general Docker command example is:

docker run -it --name teamcity-server-instance \
-v <path-to-data-directory>:/data/teamcity_server/datadir \
-v <path-to-logs-directory>:/opt/teamcity/logs \
-p <port-on-host>:8111 \
jetbrains/teamcity-server

There are a couple of options for you; you can make a backup of the database and data directory and restore it to a newer instance, or you can "swap out" the older TeamCity container with one running a later release.

How are you starting your containers? Can you share the command you use? 

Making a backup can be done with the maintainDB script built into the TeamCity image, while the container is stopped. Here is an example:

docker run -it --name teamcity-server-instance \
-v <path-to-data-directory>:/data/teamcity_server/datadir \
-v <path-to-log-directory>:/opt/teamcity/logs \
-p <port-on-host>:8111 \
jetbrains/teamcity-server \
"/opt/teamcity/bin/maintainDB.sh" "backup"

There is also a ton of information on the use of the jetbrains/teamcity-server image on the docker.io page: https://hub.docker.com/r/jetbrains/teamcity-server

0
Comment actions Permalink

Thats the thing, people who set this up just used 
```docker run teamcity-server ```

command. The image is stored in AWS ECR. The data dir, and logs are stored within the container and are not mapped on the outside host. 

0
Comment actions Permalink

I'm not sure how the data format could be upgraded if it is all within the container, it would have needed to have been accessed by a newer TeamCity instance at some point. What do you get if you run:

docker inspect -f '{{ .Mounts }}' <your teamcity container>

If you don't see a binding here, it may also be worth looking to see what the TEAMCITY_DATA_PATH environment variable is set to.

0
Comment actions Permalink

docker inspect -f '{{ .Mounts }}' teamcity-server
[{bind /tcdata /data/teamcity_server/datadir rw true rprivate} {bind /tclogs /data/teamcity_server/logs rw true rprivate} {volume e26a7e3ced00c22864c3260810f6170a1d /var/lib/docker/volumes/e2cdd565950b946a7e3ced00c22864c3260810f6170a1d/_data /opt/teamcity/logs local true } {bind /tcdata/artifactsViewer.jsp /opt/teamcity/webapps/ROOT/artifactsViewer.jsp rw true rprivate}]

0
Comment actions Permalink

It looks like the container has a binding to /tcdata and /tclogs on the host machine. If you start up another container, you could include this binding. See https://docs.docker.com/storage/bind-mounts/ for additional information on this. You may also need to find out some info on the database though. Look in /tcdata/config/database.properties to find out what kind of database is being used and where it is located. 

Before continuing to start a new container, I would recommend making a copy of the current data directory in the chance that something goes bad. Then you can start a new container with something like:

docker run -it --name teamcity-server-instance \
-v /tcdata:/data/teamcity_server/datadir \
-v /tclogs:/opt/teamcity/logs \

-p 8111:8111 \
jetbrains/teamcity-server:2019.2.4
0
Comment actions Permalink

Thanks Eric, I will try this and let you know if it worked. 

0

Please sign in to leave a comment.