| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This commit builds on the groundwork in
ee008e300b1ec0abcc90e6a30816ec0754cea0dd, which refactored the backend
so the same code could be used for new dropdowns. In this commit its
used for templates for the `.gitlab-ci.yml` files.
|
|
|
|
Limit push email diff size
Restrict the size of diffs in push emails to 30 lines / 150 KB (whichever is smaller),
following https://gitlab.com/gitlab-org/gitlab_git/merge_requests/85.
Emails on push can get very large if they contain a lot of files that sneak under the single-file limit.
https://gitlab.com/gitlab-org/gitlab-ee/issues/490
See merge request !4566
|
|
|
|
|
|
of max database values
When using #XYZ in Markdown text, if XYZ exceeds the maximum value of a signed 32-bit integer, we
get an exception when the Markdown render attempts to run `where(iids: XYZ)`. Introduce a method
that will throw out out-of-bounds values.
Closes #18777
|
|
|
|
Previously we'd create a separate Metric instance for every method call
that would exceed the method call threshold. This is problematic because
it doesn't provide us with information to accurately get the _total_
execution time of a particular method. For example, if the method
"Foo#bar" was called 4 times with a runtime of ~10 milliseconds we'd end
up with 4 different Metric instances. If we were to then get the
average/95th percentile/etc of the timings this would be roughly 10
milliseconds. However, the _actual_ total time spent in this method
would be around 40 milliseconds.
To solve this problem we now create a single Metric instance per method.
This Metric instance contains the _total_ real/CPU time and the call
count for every instrumented method.
|
|
Filter out sensitive parameters of metrics data
See merge request !4748
|
|
Allow customising of queries used for `update_column_in_batches`
This MR makes two changes to `add_column_with_default` and `update_column_in_batches`:
1. `add_column_with_default` no longer wraps the entire set of updates in a single transaction, preventing any locks from sticking around for the duration of the entire transaction
2. `update_column_in_batches` now takes a block which can be used to customise the queries. This uses Arel as messing with raw SQL strings is a total pain
In !4381 there's a need for updating existing rows/columns in a table in batches using a custom `WHERE` condition. Without the changes in this MR this would not be possible.
See merge request !4680
|
|
|
|
This changes update_column_in_batches to ensure it always updates all
rows now. These changes also allow for an extra SELECT query to be
removed, nor does it use the row count for determining offsets and the
likes; instead it's only used to determine the batch size.
|
|
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
|
|
|
|
Currently the RegexpError can be raised when processing next stage which leads to 500 in different places of code base.
This adds early check that regexps used in only and except are valid.
|
|
Limit push email diff size to 30 files or 150 KB, whichever comes first.
|
|
|
|
|
|
feature/project-export
# Conflicts:
# app/models/ci/pipeline.rb
|
|
This reverts commit 13e37a3ee5c943525a99481b855d654e97e8597c.
|
|
|
|
|
|
|
|
Get rid of Gitlab::ShellEnv
Remove obsolete code we once needed for Grack and satellites.
See merge request !4673
|
|
also fixed a small bug
|
|
This ensures that whatever locks are acquired aren't held onto until the
end of the transaction (= after _all_ rows have been updated). Timing
wise there's also no difference between using a transaction and not
using one.
|
|
By passing a block to update_column_in_batches() one can now customize
the queries executed. This in turn can be used to only update a specific
set of rows instead of simply all the rows in the table.
|
|
Add environments and deployments
This MR is a continuation of https://gitlab.com/gitlab-org/gitlab-ce/issues/17009.
The current implementation is as follow:
1. We have two new tables: `environments` and `deployments`.
2. We have a new tab: `Environments` under `Pipelines` where you can see all you environments and add a new one.
3. We add a new option to `.gitlab-ci.yml` to track where we should create a deployment for environment.
4. If environment in `.gitlab-ci.yml` is specified it will create a deployment. **If environment does not exist it will be created.** (this got changed)
5. The deployment is always successful and shows the time of the action, in that case a build that presumably should do deployment. In the future we could extend deployment with statuses: success, failure. We could extend deployments with information that this is partial or full deployment.
6. User have to create environments that he will track first.
7. User can remove environments.
8. User can retry/rollback past deployment (in that case we retry past build). The new build when succeeds it will create a new deployment.
9. Currently environment have only one parameter: `name`. In the future it should have: `variables`, `credentials` and possibly `runners` and maybe other resources.
10. Currently deployment have this parameters: `sha`, `ref`, `deployable (in this case a build)`, `user (who triggered a deployment)`, `created_at`.
The `.gitlab-ci.yml`:
```
deploy to production:
stage: deploy
script: dpl travis...
environment: production
```
What needs to be done:
- [x] Write initial implementation
- [x] Improve implementation (@ayufan)
- [x] Write tests (@ayufan)
- [x] Improve UX of the forms (cc @markpundsack) - reviewed by @markpundsack
- [x] Improve implementation of the views (cc @jschatz1) - done by @iamphill
- [x] Write .gitlab-ci.yml documentation for `environments` - done by @ayufan
- [ ] Write user documentation (@ayufan and @markpundsack)
See merge request !4605
|
|
|
|
|
|
|
|
|
|
issues, updated routes, etc...
|
|
We can't do a lot with classes without names as we can't filter by them,
have no idea where they come from, etc. As such it's best to just ignore
these.
|
|
'feature/project-import' of gitlab.com:gitlab-org/gitlab-ce into feature/project-export-ui-experimental
|
|
|
|
|
|
Instrument Grape API endpoints
See merge request !4587
|
|
Instrument private methods and instance private methods
See merge request !4639
|
|
# Conflicts:
# db/schema.rb
|
|
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
|
|
# Conflicts:
# lib/ci/gitlab_ci_yaml_processor.rb
|
|
|
|
|
|
Measure CPU time for instrumented methods
See merge request !4640
|
|
Generating the following tags
Grape#GET /projects/:id/archive
from Grape::Route objects like
{ :path => /:version/projects/:id/archive(.:format)
:version => “v3”,
:method => “GET” }
Use an instance variable to cache raw_path transformations.
This variable is only going to growth to the number of
endpoints of the API, not with exact different requests
We can store this cache as an instance variable because
middleware are initialised only once
|
|
|
