An error occurred fetching the project authors.
- 24 Feb, 2016 9 commits
-
-
Jérome Perrin authored
Since this parameter is a json encoded string, request parameter must be []
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kirill Smelkov authored
@rafael says frontend infrastructure is not yet ready to handle slave requests for frontends which come with lab.nexedi.com frontend SR URLs. So revert apache-frontend-URL related part of 86deb9c6 (*: slapos.git moved to https://lab.nexedi.com/nexedi/slapos.git) back for now. /cc @jp /reviewed-by @rafael /reviewed-on nexedi/slapos!52
-
Kirill Smelkov authored
86deb9c6 (*: slapos.git moved to https://lab.nexedi.com/nexedi/slapos.git) went over whole tree and updated slapos.git URL but when changing non-top-software.cfg-like files forgot to update their md5sum in software releases. Fixes started to appear - e.g. 8b1496c3 (kvm: fix md5sum, thanks @alain.takoudjou), but generally the whole tree remains more-or-less broken. Fix it. (not tested - manually checked files and updated md5sums) /reported-by @rafael
-
- 23 Feb, 2016 1 commit
-
-
Alain Takoudjou authored
-
- 22 Feb, 2016 1 commit
-
-
Cédric Le Ninivin authored
-
- 21 Feb, 2016 1 commit
-
-
https://lab.nexedi.com/nexedi/slapos.gitKirill Smelkov authored
This updates links to slapos.git in the tree to point to new location. We do so whole-tree except one place in stack/monitor/ : [download-monitor-static] recipe = hexagonit.recipe.download url = http://git.erp5.org/gitweb/slapos.git/snapshot/930be99041ea26b7b1186830e5eb56ef0acc1bdf.tar.gz ... (see d8800c0b "monitor: Download statics files from snapshot") The reason we do not update that link yet, is that 930be99041ea26b7b1186830e5eb56ef0acc1bdf is a tree object and gitlab does not allow to dowload tree object as archives (yet ?) So for now that link stays unconverted - and we'll think how to do with it.
-
- 19 Feb, 2016 2 commits
-
-
Vincent Pelletier authored
-
Ivan Tyagov authored
Fix image display on jupyter This fix is for bug https://nexedi.erp5.net/bug_module/20160212-76EAAC/view?ignore_layout:int=1 where the image base64 string was only showing. The error in this case was that the `mime_type` of content code_result was not being updated by the kernel before display. Reported by : @Tyagov Please review: @Tyagov @kirr For testing, you can use this jupyter instance with updated kernel running : https://[2001:67c:1254:e:8b::335d]:8888/tree There are also some example notebooks in the aforementioned jupyter. See merge request !47
-
- 18 Feb, 2016 2 commits
-
-
Rafael Monnerat authored
-
Ayush Tiwari authored
This fix is for bug https://nexedi.erp5.net/bug_module/20160212-76EAAC/view?ignore_layout:int=1 where the image base64 string was only shoeing. The error in this case was that the mime_type of content code_result was not being updated by the kernel before display. Reported by : @ivan
-
- 17 Feb, 2016 4 commits
-
-
Kirill Smelkov authored
To pick up kirr/gitlab-ce@32fa1180 /cc @kazuhiko, @jerome /reviewed-by TrustMe
-
Kirill Smelkov authored
6a4e45c5 (gitlab: Sync sidekiq service launch with upstream) claimed to sync sidekiq startup with upstream, but missed one upstream change in between 8.2 and 8.4: https://gitlab.com/gitlab-org/omnibus-gitlab/commit/2eb7634f My bad - I should have reviewed git log for https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/sv-sidekiq-run.erb and I did not noticed that change because I did not and just compared queues list visually. Pick it up. /cc @kazuhiko, @jerome /reviewed-by TrustMe (I hope)
-
Rafael Monnerat authored
-
Kirill Smelkov authored
This brings slapos gitlab port up to date with current stable gitlab version 8.4, and teaches Unicorn startup script to wait a bit for PostgreSQL to start and be ready, before unicorn startup proceeds. /cc @kazuhiko /somewhat-reviewed-by @jerome /reviewed-on nexedi/slapos!44
-
- 16 Feb, 2016 3 commits
-
-
Alain Takoudjou authored
This changes were squashed into a single commit and it includes: - install slapos_configurator by default - Allow define ssl authentication for a certain zope family - Allow define custom zope path per zope family Those changes are originally written by Alain Takoudjou and rewrited by Rafael Monnerat
-
Kirill Smelkov authored
To pick up kirr/gitlab-ce@a5965b54.
-
Rafael Monnerat authored
The local changes are not yet generic enough to be shared among stack, so Introduce local changes here better
-
- 15 Feb, 2016 5 commits
-
-
-
Rafael Monnerat authored
-
Rafael Monnerat authored
There is no strong reason to use git.erp5.org to test code anymore
-
Rafael Monnerat authored
slapos.package is not an egg anymore, it's implementation was replaced by the usage of ansible with playbooks.
-
Rafael Monnerat authored
-
- 13 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
As it was outlined in 5a744de7 (gitlab: Compile assets on instantiation and make sure DB is properly setup/migrated before unicorn runs) we are performing DB initialization and migration in pre-action as part of unicorn startup script. But that currently has one drawback: if all services start at the same time - e.g. both PostgreSQL and Unicorn - and that is a common scenario when SR is compiled and instantiated / started, PostgreSQL is usually not yet ready to process queries from Unicorn startup script, and first-time Unicorn startup fails. Until now this problem was workarounded by manually starting unicorn second time - after some time postgresql is started and ready. But why do it manually, if we can do the same logic automatically. So fix it: in Unicorn startup script wait a bit (up to 5 seconds) for PostgreSQL to become ready. /cc @kazuhiko, @jerome
-
- 12 Feb, 2016 2 commits
-
-
iv authored
This is a SR to build NayuOS binary images. More info on https://www.nayuos.com and in the README. Merging this recipe from a standalone repository was a decision made together with @kirr and @vpelletier.
-
iv authored
-
- 11 Feb, 2016 9 commits
-
-
Kirill Smelkov authored
Even though we do not use LFS objects, builds and build artifacts, gitlab backups corresponding directories and recreates them upon restore. Current state is: the directories are living under Rails root - that is in our gitlab-work/ inside instance, and since gitlab-work is recreated almost on every re-instantiation if we'll have some content in that directories - it will be lost. Don't allow even a chance for that to happen and move what is designed to hold data to under var/ . NOTE we create shared/lfs-objects/ and shared/artifacts/ because if we do not have this dirs, gitlab backup fails. Upstream code just assumes the directories are there. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Upstream added `pages` and `elasticsearch` queues to sidekiq https://gitlab.com/gitlab-org/omnibus-gitlab/commit/be6844ff https://gitlab.com/gitlab-org/omnibus-gitlab/commit/801d6ed7 but since those queues are used for EE-only services we do not enable them. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
As gitlab-workhorse is now serving everything, it proxies unknown-to-it requests to unicorn, and that returns redirect to /users/sign_in for /non-existent, not 403. Adjust the promise and just verify whether we can get /static.css NOTE nginx promise now effectively depends on gitlab-workhorse being up and running - because nginx is now configured to be only an SSL terminator and all requests processing is done by gitlab-workhorse and services below it. If in the future we'll need a pure nginx-is-up promise, we can introduce something to nginx config and verify that particular http endpoint. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
add `-documentRoot ...` argument to gitlab-workhorse start as upstream started to do: https://gitlab.com/gitlab-org/omnibus-gitlab/commit/d769f751 ( gitlab-workhorse now needs to know where document root is as it now serves all content - e.g. static files too this option was introduced here: https://gitlab.com/gitlab-org/gitlab-workhorse/commit/1a7009e4 ) /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
I manually reviewed files/gitlab-config-template/gitlab.rb.template files/gitlab-cookbooks/gitlab/attributes/default.rb from omnibus-gitlab 8.4.2+ce.0-3-g68d5ee8 and picked up changes: - unicorn OOM killer memory limits were raised up (because gitlab is now more memory hungry according to talks on gitlab.com) https://gitlab.com/gitlab-org/omnibus-gitlab/commit/f8ee4a19 - there is no default limit for nginx client_max_body_size - it just goes to gitlab-workhorse as is at any size https://gitlab.com/gitlab-org/omnibus-gitlab/commit/78862837 /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Direct merge for gitconfig.erb from omnibus-gitlab did not brought up updates. pack.threads=1 and receive.fsckObjects=true picked up from https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb in 264d785a stay the same. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
No changes. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
- there is a section for gitlab pages, which we stub-out; - there is no longer a need to add /raw/... handling to nginx - as now nginx is just an SSL terminator for gitlab-workhorse, all URL handling is done inside gitlab-workhorse and is dealt with ok by our patches. - as now nginx does not directly connect to unicorn, there is no need to pass unicorn section to nginx's template. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like wih gitlab configs, this does only pure merge. We will slaposify / adjust to updates in the following patches. /cc @kazuhiko, @jerome
-