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
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.
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.
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
- 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.
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.
Closesgitlab-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.
Closesgitlab-com/support-forum#678
Kamil Trzcinski
Rémy Coutable
Douwe Maan
Yorick Peterse
Z.J. van de WegandYorick Peterse
David AlexanderandRémy Coutable
Douglas Barbosa Alexandre
Douwe Maan
Felipe Artur
Paco GuzmanandYorick Peterse
Rui AndersonandRémy Coutable
Sean McGivern
Jacob Schatz
Thijs WoutersandAlfredo Sumaran
Timothy Andrew
Stan Hu
James Lopez
Josh Frye