Some of the tests fail locally due to the git user being different
than it is on the test runners. I'd really like to be able to run
all of the tests locally.
The change in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24199 caused
requests coming from a load balancer to arrive as 127.0.0.1 instead of
the actual IP.
`Rack::Request#ip` behaves slightly differently different than
`ActionDispatch::Request#remote_ip`: the former will return the first
X-Forwarded-For IP if all of the IPs are trusted proxies, while the
second one filters out all proxies and falls back to REMOTE_ADDR, which
is 127.0.0.1.
For now, we can revert back to using `Rack::Request` because these
middlewares don't manipulate parameters. The actual fix problem involves
fixing Rails: https://github.com/rails/rails/issues/28436.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58573
Mixing and matching the use of Rack::Request and ActionDispatch::Request
in Rails 5 is bad, particularly if you have middleware that
manipulates or accesses environment variables.
`Gitlab::Middleware::Multipart` attempts to rewrite request parameters
to the proper values (e.g. replacing `data_file` with
`UploadedFile`). It does this by calling `Rack::Request#update_params`,
which essentially updates `env['rack.request.form_hash']`.
By changing to `ActionDispatch::Request`, the Go middleware was causing
the request parameters to be stored inside
`env['action_dispatch.request.request_parameters']`. Later calls to
`Rack::Request#update_params` would not have any effect because it would
attempt to update `env['rack.request.form_has']` instead of
`env['action_dispatch.request.request_parameters']`. As a result, the
controller still saw the old parameters.
Since the Go middleware appears to be using `ActionDispatch::Request`
for authorization methods, we can switch the multipart middleware to
use it too.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/9035
When direct_upload is enabled and a for file is being uploaded,
then workhorse uses `public/uploads/tmp` path. If `uploads.storage_path`
i sset to a different directory, then upload fails because
`public/uploads/tmp` is not in allowed paths.
The previous implementation would hit the database each time
and provide a dummy response. If the database goes down, this
means all application workers would be taken out of service.
Simplify this check by using a Rails middleware that intercepts
this endpoint and returns a 200 response.
* upstream/master: (889 commits)
SlackService - respect `notify_only_default_branch` for push events
Clarify usage ping wording in admin area
Update incoming emails documents
Allow to include also descendant group labels
Update docs on grouping CI jobs
Support additional LabelsFinder parameters for group labels
Extend Cluster Applications to install GitLab Runner to Kubernetes cluster
Remove registry list webpack entry point
Remove trailing newline that was causing an EE conflict
Small fixes in Vuex docs
Remove u2f webpack bundle
Update documentation WRT to request parameters
remove common_vue CommonsChunk config
Fetch commit signatures from Gitaly in batches
migrate stl_viewer to dynamic import
migrate sketch_viewer to dynamic import
migrate pdf_viewer to dynamic import
migrate notebook_viewer to dynamic import
migrate balsamiq_viewer to dynamic import
Add some strings that were missing in gitlab.pot
...
In the attempt to unify file uploading at workhorse level gitlab-org/gitlab-workhorse!230
we moved to a prefix-based tempfile creation in order to avoid upload collisions.
Artifacts and LFS uploads already set original_filename to workhorse provided filename
This commit add the same feature to `Gitlab::Middleware::Multipart`
So that we don't need to hold env after the request.
This makes it much harder to test, especially Rails session is
acting weirdly, so we need `dig('flash', 'flashes', 'alert')`
to dig the actual flash value.
after the request. This way, we could release the
project referred from the controller, which potentially
referred a repository which potentially allocated a lot of
memories.
Before this change, we could hold the last request data
and cannot release the memory. After this change, the
largest request data should be able to be collected from GC.
This might not impact the instances having heavy load,
as the last request should be changing all the time,
and GC won't kick in for each request anyway.
However it could still potentially allow us to free more
memories for each GC runs, because now we could free one
more request anyway.
GitLab Bot
Robert Speicher
Thong Kuah
David H. Wilkins
Stan Hu
Ash McKenzie
mortyccp
Jasper Maes
Marcel Amirault
Jan Provaznik
Mark Chao
Brett Walker
Kamil Trzciński (OoO till 3th)
Lin Jen-Shin
Douwe Maan
Alessio Caiazza