versions in config-captain.json

[drmrbrewer]

My config-captain.json file is getting ever bigger. Question is... is there really a need for all of the entries in the versions element?

"versions": [
    {
            "version": 0,
            "timeStamp": "2018-01-31T20:55:54.507Z"
    },
    {
            "version": 1,
            "timeStamp": "2018-01-31T21:00:51.759Z",
            "gitHash": "dc49fc547eaa14ee5784364af40645fd9aaf24a8"
    },
    ...
    ...

Can I cull these at all?

[githubsaturn]

It's a deploy history. CapRover adds the feature for one click rollbacks. Now all these information is being used. If it really bothers you, you can cleanup the config file and restart your captain-captain. But it really shouldn't be an issue. Each deploy is around 150 bytes. If you deploy 2 times a day for 365 days for 10 apps, it adds around 1 MB to your config file. This shouldn't be an issue.

[drmrbrewer]

I agree it's not a big deal. The only reason I noticed it is because I do an auto backup once a day, and saw it creeping up and up. Could we in theory do a one-click rollback to any version in the history? Would only seem necessary to keep any part of the history that is still useable, so if it's all useable, then that's fine.

Another (slightly related) thing I noticed, playing around with CapRover for the first time, is this... in my server-spinup script I install captain / caprover, then immediately scale it to 0, fetch my captain / caprover backup (and do some "manual" tweaks) and then scale up to 1 again. This used to be fine with captain but now, after installing caprover, I seem to need to wait a few seconds before scaling to 0, otherwise the /captain folder structure doesn't seem properly populated... does that make any sense? Again, I seem to have it working by inserting a sleep 15 in my script after installing caprover, so this question is more out of curiosity than anything.

[githubsaturn]

There is a lot that has changed in startup procedure. One thing that I personally noticed was the delay caused by upgrading Certbot (LetsEncrypt Client) from v0.17 to v0.29. It used to be ready in a fraction of a second, now it takes ~10 sec or more to spin up. That could be the cause of the delay.

[githubsaturn]

Regarding rollback, yes, any version can be rolled back to. Unless you had deleted the image. Even so, it's a deployment history. It's better to keep it. Trying to rollback to an image that was manually deleted doesn't break your app, it just doesn't work, the rollback will gracefully fail.

[drmrbrewer]

At what point in the process does the Certbot upgrade take place?

Regarding rollback, I tend to clear out images on a fairly regular basis to keep storage in check, and would only see real value in rolling back to the previous version (after a bad deploy) or maybe two or three at the most. My main app now has 670 version entries in the conf file... I would never ever ever consider rolling back 670 versions even if I could.

[githubsaturn]

At what point in the process does the Certbot upgrade take place?

Start up. It's not the "upgrade" that takes time, it's the start up process of Certbot and having it connect to CapRover.

Regarding rollback, I tend to clear out images on a fairly regular basis to keep storage in check, and would only see real value in rolling back to the previous version (after a bad deploy) or maybe two or three at the most. My main app now has 670 version entries in the conf file... I would never ever ever consider rolling back 670 versions even if I could.

Fair enough. Like I said, as part of your script, you can remove the unwanted elements of the "versions". I've made some changes to CapRover to ensure that it can handle missing elements of versions gracefully. It will cause no problem.

[githubsaturn]

Fair enough. Like I said, as part of your script, you can remove the unwanted elements of the "versions". I've made some changes to CapRover to ensure that it can handle missing elements of versions gracefully. It will cause no problem.

Just realized that this bit is not released yet. Please wait until v.1.2.0 comes out (in a day or two)

[drmrbrewer]

it's the start up process of Certbot and having it connect to CapRover

That probably explains it then. I need to give CapRover a little time to settle before scaling it 0 and messing with the configuration files, which I didn't with captainduckduck.

[drmrbrewer]

@githubsaturn I still think it would be nice to have an automated way to clean up the deployment history :) It doesn't take up much disk space, but if nothing else it just clutters up the config file and when I'm looking through the config file (to plan my next customisation :) all this history just gets in the way... I know that I'm never going to go back more than a couple of versions, not least because I'm using a self-hosted registry and the images are cleaned out on a regular basis (e.g. when I spin up a new server) so keeping this history seems pointless. Yes it's possible to edit the file manually, but it would be nice to have an option to clear out any history older than e.g. 6 months... that would keep things in check.

[githubsaturn]

The version history is capped at 50 by default:

caprover/src/utils/CaptainConstants.ts

Lines 27 to 29 in 6fdcb8b

	maxVersionHistory: 50,

You can override it via config override