| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Gravatar, Google Analytics, Piwik, Recaptcha, etc.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This allows us to drop our disable email config override
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This stands as an alternative to using OAuth to access a user's Github
repositories. This is setup in such a way that it can be used without OAuth
configuration.
From a UI perspective, the how to import modal has been replaced by a full
page, which includes a form for posting a personal access token back to the
Import::GithubController.
If the user has logged in via GitHub, skip the Personal Access Token and go
directly to Github for an access token via OAuth.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make Rack::Request use our trusted proxies when filtering IP addresses
## What does this MR do?
This allows us to control the trusted proxies while deployed in a private network.
## Are there points in the code the reviewer needs to double check?
If we want to limit what is impacted, we can do this specifically for the rack_attack request object.
## Why was this MR needed?
Normally Rack::Request will trust all private IPs as trusted proxies, which can cause problems if your users are connection on you network via private IP ranges.
Normally in a rails app this is handled by action_dispatch request, but rack_attack is specifically using the Rack::Request object instead.
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/17550
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [ ] ~~API support added~~
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
\cc @stanhu
See merge request !4958
|
| | |
| |
| |
| |
| |
| | |
This allows us to control the trusted proxies while deployed in a private network. Normally Rack::Request will trust all private IPs as trusted proxies, which can caue problems if your users are connection on you network via private IP ranges.
Normally in a rails app this is handled by action_dispatch request, but rack_attack is specifically using the Rack::Request object instead.
|
| | |
| |
| |
| | |
install task
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
Add SMTP as default delivery method to match gitlab-org/omnibus-gitlab!826
Something happened after upgrading to 8.9RC5 that caused mail settings to be set to sendmail by default. gitlab-com/infrastructure#128 describes the issue in more detail. This MR mirrors the change in omnibus with gitlab-org/omnibus-gitlab!826.
Closes #19132
See merge request !4915
|
| | |
| |
| |
| |
| |
| | |
Closes #19132
[ci skip]
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disable the email checking part of the standard Health Check
## What does this MR do?
In order to fix it we have overwritten the email_configured? method in the health check so that it does not check email status during the standard health check.
## Why was this MR needed?
The email check used in the Heath Check doesn't properly make use of enough of the SMTP config options to be able to properly test the STMP connection, and as a result could cause a failure.
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/17742
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support added~~
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4903
|
| | |
| |
| |
| | |
There was nothing additional in the full checks that we want to run (email, custom)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The email check used in the Heath Check doesn't properly make use of enough of the SMTP config options
to be able to properly test the STMP connection, and as a result could cause a failure.
In order to fix it we have overwritten the email_configured? method in the health check
so that it does not check email status during the standard health check.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit changes the way certain documents are rendered (currently
only Notes) and how documents are redacted. Previously both rendering
and redacting would run on a per document basis. The result of this was
that for every document we'd have to run countless queries just to
figure out if we could display a set of links or not.
This commit changes things around so that redacting Markdown documents
is no longer tied into the html-pipeline Gem. This in turn allows it to
redact multiple documents in a single pass, thus reducing the number of
queries needed.
In turn rendering issue/merge request notes has been adjusted to take
advantage of this new setup. Instead of rendering Markdown somewhere
deep down in a view the Markdown is rendered and redacted in the
controller (taking the current user and all that into account). This has
been done in such a way that the "markdown()" helper method can still be
used on its own.
This particular commit also paves the way for caching rendered HTML on
object level. Right now there's an accessor method Note#note_html which
is used for setting/getting the rendered HTML. Once we cache HTML on row
level we can simply change this field to be a column and call a "save"
whenever needed and we're pretty much done.
|
| | | |
|
| |/
|
|
|
|
| |
Hamlit is a library that's faster than Haml while implementing most of its features: https://github.com/k0kubun/hamlit
Not sure if this breaks anything, but as far as I can tell most things work the same. No obvious regressions that I've been able to find.
|
| | |
|
| |
|
|
|
|
| |
By eager-loading the Mail gem in the Sidekiq initializer.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Export project functionality
This is a MR for the export functionality of https://gitlab.com/gitlab-org/gitlab-ce/issues/3050, which adds the ability to export single projects.
- [x] members
- DB data
- [x] issues
- [x] issue comments
- [x] merge requests
- [x] merge request diff
- [x] merge request comments
- [x] labels
- [x] milestones
- [x] snippets
- [x] releases
- [x] events
- [x] commit statuses
- [x] CI builds
- File system data
- [x] Git repository
- [x] wiki
- [x] uploads
- [ ] ~~CI build traces~~
- [ ] ~~CI build artifacts~~
- [ ] ~~LFS objects~~
- DB configuration
- [x] services
- [x] web hooks
- [x] protected branches
- [x] deploy keys
- [x] CI variables
- [x] CI triggers
See merge request !3114
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Resolve "Track the number of new Redis connections per transaction"
## What does this MR do?
Add a new metric counter, `new_redis_connections`, that contains the number of calls to `Redis::Client#connect` in the current transaction.
## Are there points in the code the reviewer needs to double check?
Not sure. I tested this in kind of a brute-force way:
1. Add a debugger in the monkey-patched `connect` method.
2. With metrics enabled, start the app and load a page.
3. The first Redis connection is created by `Rack::Attack` and isn't in a transaction, but still works fine.
4. The second Redis connection is within a transaction (the page load), and increments the counter.
5. If I reload the page, neither debugger is hit.
6. If I use a Redis client and do `CLIENT KILL` on my two existing clients, then reload the page, I get 3 and 4 again.
7. If I disable metrics collection, the debugger never gets hit.
## Why was this MR needed?
We may have a Redis connection leak somewhere, so adding metrics will let us track this.
## What are the relevant issue numbers?
Closes #18451.
## Screenshots (if relevant)
Hahaha nope, not relevant.
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- [ ] Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @yorickpeterse
See merge request !4649
|
| | | |
| | |
| | |
| | |
| | | |
Increment the counter `new_redis_connections` on each call to
`Redis::Client#connect`, if we're in a transaction.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Instrument private methods and instance private methods
See merge request !4639
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
By default instrumentation will instrument public,
protected and private methods, because usually
heavy work is done on private method or at least
that’s what facts is showing
|
| |\ \ \
| |/ / |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improve Gitlab::Auth method names
Auth.find was a very generic name for a very specific method.
Auth.find_in_gitlab_or_ldap was inaccurate in GitLab EE where it also
looks in Kerberos.
See merge request !4589
|
| | | |/
| | |
| | |
| | |
| | |
| | | |
Auth.find was a very generic name for a very specific method.
Auth.find_in_gitlab_or_ldap was inaccurate in GitLab EE where it also
looks in Kerberos.
|
| |\ \ \
| |/ / |
|
| | |/
| |
| |
| |
| | |
Now that this code is no longer part of Banzai::Filter it needs to be
instrumented explicitly.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
git-http-controller
Conflicts:
lib/gitlab/workhorse.rb
|
| | |
| |
| |
| | |
This worker is called manually by `RepositoryCheck::BatchWorker` meaning it's not tracked automatically by the Sidekiq middleware.
|
