| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
# Conflicts:
# app/views/layouts/nav/_project.html.haml
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Artifacts expire date
What do you think @grzesiek?
The syntax will be simple:
```
job:
artifacts:
expire_in: 7d
```
- [x] Implement `expire_in`
- [x] Check current design of expiry information with @jschatz1 and @markpundsack
- [x] Add tests in GitLab application for a `ExpireBuildArtifactsWorker` and for `ArtifactsController::keep`
- [x] Add user documentation how to use `artifacts:expire_in`
- [x] Prepare GitLab Runner changes to pass `expire_in`: gitlab-org/gitlab-ci-multi-runner!191
- [x] Fix `timeago` with help of @jschatz1
- [x] Merge latest master after builds view changes @iamphill
- [ ] Add Omnibus support for `expire_build_artifacts_worker` cron job
- [ ] Add documentation how to configure `expire_build_artifacts_worker`
This is based on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4201.
See merge request !4200
|
| | | |\ |
|
| | | | | |
|
| | | |\ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
MySQL apparently doesn't support executing multiple queries in the same
`execute` call so we have to use a separate one for the "LOCK TABLES"
statement.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As suggested by @yorrickpeterse in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4581#note_12373882
the locking of the MySQL database wasn't correct.
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit does two things:
1. It adds logic which prevents timing issues when running the
migration. During the migration, notes can be created which _should_
be award emoji and thus migrated. To prevent these timing issues, a
lock is obtained on the table (MySQL) or on Transaction level (PG).
2. There was no down migration before as you'd probably lose some data.
Data effected is all awards on notes. These could be migrated back, as
the noteable type would just be Note, though this would litter the DB
with data which should not be there. This down migration does not yet
delete the table.
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/ / / |
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| |
| |
| | |
The schema doesn’t reflect the changes of the last 3 migrations:
* 20160610140403_remove_notification_setting_not_null_constraints.rb
* 20160610201627_migrate_users_notification_level.rb
* 20160610301627_remove_notification_level_from_users.rb
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Remove notification level from user model
part of #3359
See merge request !4494
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Using update_column to store the boolean flag to avoid
any side effects with the current state of the project
instance
|
| |
|
|
|
|
|
|
| |
#mergeable_ci_state?
The logic of the method was obviously inverted.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
| |
Migrations shouldn't fail RuboCop checks - especially lint checks, such
as the nested method check. To avoid changing code in existing
migrations, add the magic comment to the top of each of them to skip
that file.
|
| |
|
|
|
|
|
|
| |
Add a new application setting, after_sign_up_text. This is text to be
rendered as Markdown and shown on the 'almost there' page after a user
signs up, but before they've confirmed their account.
Tweak the styles for that page so that centered lists look reasonable.
|
| |
|
|
|
|
|
|
|
|
|
| |
This improves performance of the duplicate notification settings
migration by removing duplicates in batches instead of using one big
"DELETE FROM" query.
The previous query would locally run over 45 minutes without even
finishing. This new setup finished in a matter of seconds.
Fixes #18289
|
| |\
| |
| |
| |
| |
| |
| | |
Ability to prioritize labels
Closes #14189
See merge request !4009
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ |
|
| | | | |
|
| | |\ \
| | |/
| |/|
| | |
| | | |
Remove duplicated notification settings and add unique index
See merge request !4472
|
| | | | |
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
# Conflicts:
# spec/features/builds_spec.rb
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- To hold registrations from U2F devices, and to authenticate them.
- Previously, `User#two_factor_enabled` was aliased to the
`otp_required_for_login` column on `users`.
- This commit changes things a bit:
- `User#two_factor_enabled` is not a method anymore
- `User#two_factor_enabled?` checks both the
`otp_required_for_login` column, as well as `U2fRegistration`s
- Change all instances of `User#two_factor_enabled` to
`User#two_factor_enabled?`
- Add the `u2f` gem, and implement registration/authentication at the
model level.
|
| |\ \ \
| |/ / |
|
| | |\ \
| | |/ |
|
| | | | |
|
| | |\ \ |
|
| | |\ \ \ |
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
# Conflicts:
# app/controllers/projects/merge_requests_controller.rb
# app/models/note.rb
# db/schema.rb
# spec/models/note_spec.rb
|
| | | | | | | |
|
| | |\ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | |_|_|_|_|/
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Remove project notification settings associated with deleted projects
On GitLab.com, there are 1560 project notification settings with no valid project all created on 2016-04-15 10:38:53 for some reason. This migration should purge
those entries.
b8f38437 should prevent this issue from occurring in the first place.
Closes gitlab-com/support-forum#678
See merge request !4311
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On GitLab.com, there are 1560 project notification settings with no valid project
all created on 2016-04-15 10:38:53 for some reason. This migration should purge
those entries.
b8f38437 should prevent this issue from occurring in the first place.
Closes gitlab-com/support-forum#678
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is not needed when we specify a default.
|
| | | | | | | |
|
