Rethink Gitlab Dependency Documentation
Background:
When upgrading Gitlab you often have the issue that rake tasks are failing because of missing dependencies.
For example: if you upgrading from 9.3.7 to 9.3.8 you have to install libre2-dev
to successfully run bundler.
What questions are you trying to answer?
How can we avoid such problems in the future?
Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?
There are several ways you can go for this. In my opinion none of them are really good. Maybe we can figure out something new.
1: Add the new dependency to the Upgrade-Barometer in the Release Blogpost.
Pro: If you upgrade you can see what you have to do. In most cases you should already check the barometer to verify if downtimes are required.
Con: If you skip the particular patch you will miss the dependency.
2: Add them to the upgrade guide for minor/major updates
Pro: You will to bigger changes (node, ruby,go) anyways. So it's a good place to store. Also if you skip the patches you will have the dep.
Con: Either you will maintain two places (barometer, upgrade guide) or you will miss one place.
3: The installation guide
You will also have to maintain the dependencies in the installation guide.
What to do?
So if you consider all these steps, you have to maintain a lot of places and it is still very likely that a user will miss a new package or a developer will forgot to update it in some places.
Maybe we can find something more central to keep such things?