Question about upgrade output data

I’m a professional sysadmin and I’m configuring a new server. So far, I’ve found the rather verbose output of each upgrade to be a bit time consuming. It may only take a few minutes to do an upgrade, but it literally takes over an hour to review the 4000+ lines of output for each upgrade. This is not only boring but not very productive. The only reason to review it is to ensure that I’m not overlooking an error that may have occurred.

What do others do in this situation? Is there a way to limit the output to only things that are important? It seems unlikely that others would read any of it, which leads me to wonder why it is so verbose if it doesn’t have to be (too much information is just as bad as too little).


The output includes the database migrations. If your upgrade works why are you reviewing it? I personally only read it if an upgrade was to fail. So save yourself time by simply not reading it since if your upgrade worked then it means its ok.

Depending on how often you upgrade, database migrations are only a rare occurrence in the output.

It might also matter if you use the standard procedure or the so-called “zero downtime” (which includes downtime) procedure for upgrades. I only have (recent) experience with the latter, and I guess the main source of output from that is the reconfiguration. I don’t know of any way to reduce that.

Because it depends on your definition of “upgrade worked”. How do you know it worked? How do you validate that it worked?

I only administer the system, I don’t use it myself. I suspect that this is more common than anyone realizes. I need to be able to upgrade without wasting a ton of time on reading useless debug data. Up to version 13.4, there doesn’t appear to be any consensus on the definition of “upgrade worked”. Is there any definitive documentation on what constitutes a successful upgrade?

Fellow sysadmin here, also user of GitLab.

After the final upgrade, it lists some of the overall status.

  1. But if you wish to do a quick sanitize check. On application health, I find these helpful.

gitlab-rake gitlab:check SANITIZE=true
gitlab-ctl status

The sanitize runs through all the key components letting you know if it’s up or not.

  1. One could go through all the lines, which is fine. If you want to ‘skim’, a low tech way is to grep for ‘warning | errors | …whatever else keywords you like’. If on windows, or you take the linux logs and copy it to windows and use utilities like cmtrace.exe which can highlight some of those things for you.

Personally speaking, I prefer more info than less, then as sysadmin, you can decide whether or not you want to read all of it.

As far as “What constitutes a successful upgrade”, after upgrade from sysadmin perspective. Review the logs and seeing the new version number.

This is good and all, but application checkout is really key. Can the users log in? Can they do a checkout, commit, merge request. Do the pipelines still run. If organizationally speaking that’s not you, then should get a product owner/power user in your company to do it.

1 Like