- Oct 09, 2013
-
-
Johannes Schleifenbaum authored
If you are running another sidekiq instance on your server, e.g. GitLab CI, the check script would parse the output of `ps aux` searching for `sidekiq` and returning success, although the GitLab sidekiq may not be running. Now the `ps` call will only print the processes run by the GitLab user.
-
Jacob Vosmaer (GitLab) authored
-
Hiroyuki Sato authored
* GitLab Shell 1.7.1 is required * Global projects are not supported (refs #5152)
-
Marin Jankovski authored
-
- Aug 27, 2013
-
-
James Newton authored
-
- Jul 18, 2013
-
-
Dmitriy Zaporozhets authored
Use gitlab-shell authorized_keys truncation. Fix issue with authorized_keys stored in different location
-
- Jul 16, 2013
-
-
Dmitriy Zaporozhets authored
-
- Jun 06, 2013
-
-
Sato Hiroyuki authored
When the file that pointed git bin_path in gitlab.yml dose'nt exist, bundle rake gitlab:app:check would be aborted. refs #4205
-
- Jun 04, 2013
-
-
Achilleas Pipinellis authored
Signed-off-by:
Axilleas Pipinellis <axilleas@archlinux.gr>
-
- May 27, 2013
-
-
bassrock authored
-
- May 19, 2013
-
-
Ben Bodenmiller authored
-
- May 16, 2013
-
-
MeiHui FAN authored
e.g.: the sidekiq in my Debian box is v2.11.1
-
- May 14, 2013
-
-
Sato Hiroyuki authored
-
- May 08, 2013
-
-
Sato Hiroyuki authored
It returns "yes" if required version is "1.7.10" and current version is "1.6.10", because the patch version of current version equals to that of required version.
-
- May 07, 2013
-
-
Sato Hiroyuki authored
Checking is "yes" only if git version equals "1.7.10" exactly.
-
- May 06, 2013
-
-
Dmitriy Zaporozhets authored
-
- Apr 30, 2013
-
-
Dmitriy Zaporozhets authored
-
- Apr 20, 2013
-
-
Dmitriy Zaporozhets authored
-
- Apr 15, 2013
-
-
Achilleas Pipinellis authored
Checking the redis version will warn users that are using an old version to update. Included reference to the troubleshooting guide.
-
Achilleas Pipinellis authored
-
Achilleas Pipinellis authored
-
- Apr 14, 2013
-
-
Achilleas Pipinellis authored
Checking the redis version will warn users that are using an old version to update. Included reference to the troubleshooting guide.
-
- Mar 28, 2013
-
-
Evan Wondrasek authored
-
- Mar 25, 2013
-
-
Dmitriy Zaporozhets authored
-
- Mar 12, 2013
-
-
Dmitriy Zaporozhets authored
-
- Feb 20, 2013
-
-
Achilleas Pipinellis authored
-
- Feb 12, 2013
-
-
Martin Bastien authored
-
Martin Bastien authored
Fixing issue #2970
-
- Feb 11, 2013
-
-
Dmitriy Zaporozhets authored
-
Dmitriy Zaporozhets authored
-
- Feb 09, 2013
-
-
Dmitriy Zaporozhets authored
-
- Feb 01, 2013
-
-
Riyad Preukschas authored
-
Riyad Preukschas authored
-
- Jan 26, 2013
-
-
Alex Denisov authored
-
- Jan 18, 2013
-
-
Kevin Lamontagne authored
Running the recommendation would give out: GNU find: paths must precede expression
-
- Jan 16, 2013
-
-
Riyad Preukschas authored
Fixes #2608
-
Riyad Preukschas authored
-
- Jan 14, 2013
-
-
VonC authored
The tasks gitlab:env:info mixes user and group, and presume as a group 'git'. However, gitolite group name can be anything. That patch add the git group name in the config, and check gitolite.ssh_user group against git.group (which defaults to 'git', as before this patch, if undefined). M config/gitlab.yml.example: Add 'group' in 'git' section Mention default value for the two extra settings M lib/tasks/gitlab/check.rake: Check that gitolite.ssh_user *group* is the one defined in git.group. Make sure to default to 'git' as the expected group if said group is undefined in the config. Note: uses a more complete regexp for the group detection (the group can start, end or be in the middle or the list of groups of gitolite.ssh_user) M: config/initializers/1_settings.rb: Add default values for gitolite.group and gitlab.user
-
- Jan 12, 2013
-
-
Riyad Preukschas authored
-
Riyad Preukschas authored
-