gitlab_rails['packages_object_store_remote_directory'] = "packages" # The bucket name.
gitlab_rails['packages_object_store_direct_upload'] = false # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
gitlab_rails['packages_object_store_remote_directory']="packages"# The bucket name.
gitlab_rails['packages_object_store_direct_upload']=false# Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
gitlab_rails['packages_object_store_background_upload']=true# Temporary option to limit automatic upload (Default: true).
gitlab_rails['packages_object_store_proxy_download']=false# Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
-`id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
-`sha` (optional) - The commit SHA to download. A tag, branch reference, or SHA can be used. This defaults to the tip of the default branch if not specified. For example:
@@ -484,9 +484,11 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
Below we describe the different pathing that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
### Web Request (80/443)
TODO
### SSH Request (22)
TODO
## System Layout
...
...
@@ -505,7 +507,9 @@ To summarize here's the [directory structure of the `git` user home directory](.
### Processes
ps aux | grep '^git'
```sh
ps aux | grep'^git'
```
GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
Instead of just overriding `Base#execute`, we should update it and extract
the behaviour into another method:
Instead of just overriding `Base#execute`, we should update it and extract
the behaviour into another method:
```ruby
class Base
def execute
return unless enabled?
```ruby
classBase
defexecute
returnunlessenabled?
do_something
end
do_something
end
private
private
def do_something
# ...
# ...
end
defdo_something
# ...
# ...
end
```
end
```
Then we're free to override that `do_something` without worrying about the
guards:
Then we're free to override that `do_something` without worrying about the
guards:
```ruby
module EE::Base
extend ::Gitlab::Utils::Override
```ruby
moduleEE::Base
extend::Gitlab::Utils::Override
override :do_something
def do_something
# Follow the above pattern to call super and extend it
end
override:do_something
defdo_something
# Follow the above pattern to call super and extend it
end
```
end
```
This would require updating CE first, or make sure this is back ported to CE.
This would require updating CE first, or make sure this is back ported to CE.
When prepending, place them in the `ee/` specific sub-directory, and
wrap class or module in `module EE` to avoid naming conflicts.
...
...
@@ -1038,8 +1038,8 @@ to avoid conflicts during CE to EE merge.
Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE
code base. Examples of backports include the following:
* Features intended or originally built for EE that are later decided to move to CE
* Sometimes some code in CE may impact the EE feature
- Features intended or originally built for EE that are later decided to move to CE
- Sometimes some code in CE may impact the EE feature
Here is a workflow to make sure those changes end up backported safely into CE too.
