Make it possible to lock runner on a specific project
Make it possible to lock runner on a specific project.
----
----
Closes#3407
See merge request !4093
Allow creating Personal Access Tokens through the website
Related to #2979
- Allow a user to create personal access tokens, and use them to authenticate
- Refactor `API::Helpers` into `API::Helpers::Core` and `API::Helpers::Authentication`
# Tasks
- [ ] #2979 (!3749) - Personal Access Tokens
- [x] Basic Implementation
- [x] Add UI to add "Personal Access Tokens"
- [x] Reload `lib/api` on every request
- [x] Respect these tokens for API requests
- [x] Just a param or a header too?
- [x] Allow revoking tokens
- [x] Expire tokens
- [x] Left bar should have a "PAT" icon
- [x] Scopes?
- [x] Copy to Clipboard
- [x] Show active/inactive tokens separately
- [x] No need to check for expired/revoked in the appropriate places
- [x] Why does regular ApplicationController check for private token?
- [x] Support non-API requests
- [x] Revert (or work on) `lib/api` eager loading
- [x] Create MR
- [x] Refactoring
- [x] Fix tests
- [x] Write more tests
- [x] Add screenshots to MR
- [x] Add description of query performance to MR
- [x] Limit the number of queries in the `personal_access_tokens` page
- [x] Wait for CI to pass
- [x] Fix merge issues in schema.rb
- [x] Assign MR to endboss
- [x] Wait for feedback
- [x] Fix feedback
- [x] Wait for CI to pass
- [x] Assign to @rspeicher
- [x] Fix @rspeicher's comments
- [x] Wait for CI to pass
- [x] Assign back to @rspeicher
- [x] Write documentation and ping @axil
- [x] Wait for Axil to respond
- [x] Assign to endboss
- [x] Address Douwe's feedback
- [x] Use the `private_token` or `authentication_token` param instead of `personal_access_token`
- [x] Ditto for the header
- [x] Assign to endboss
- [x] Make sure CI is green
- [x] Address Douwe's feedback
- [x] Don't go through the `authenticate_user_from_private_token!` method, if a private token is supplied (or combine them)
- [x] In `authenticate_user_from_personal_access_token!` don't hit DB if `token_string` is `nil`
- [x] Use `current_user.personal_access_tokens.build` in the controller
- [x] Remove the "We aren't using `personal_access_token` as the root param" comment
- [x] `No need for = "...", we can just have the Inactive ... #{...} on the next line` in the view
- [x] Render dates in a (more) human format
- [x] CSS issue with table
- [x] Don't show the tokens in the UI indefinitely
- [x] How to implement scopes? Add-on to current impl? Doorkeeper?
- [x] Wait for @DouweM's comments about scopes
- [x] Address @DouweM's second review
- [x] Try not using `native['innerHTML']`
- [x] use contexts for all "when ..."
- [x] Ensure consistency (styling) with other pages for "You don't have any tokens" message
- [x] "Actions" table column doesn't need a label
- [x] %td can be moved outside of the if/else statement
- [x] The header title should be "Profile Settings"
- [x] Can this be a `before_create`, so we don't need to use `generate`?
- [x] If it couldn't be revoked, will we show an error?
- [x] If it couldn't be saved, will we show an error?
- [x] Merge master
- [x] Update CHANGELOG entry
- [x] Add tests for form errors?
- [x] Post screenshots
- [x] Tag @jschatz1 for review
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/0dff6fd/builds) to pass
- [x] Respond to @jschatz1's comments
- [x] Hardcoded colors should be variables
- [x] Should not be allowed to chose a date in the past
- [x] Use the same table as in the Applications tab
- [x] button should say "Create Personal Access Token"
- [x] Float the revoke to the right on the `a`
- [x] Change revocation message. "Are you sure you want to revoke this certificate? This action cannot be undone."
- [x] Date stays selected and looks selected even though date is set as "never".
- [x] ~~hover on the calendar button shifts~~ (not caused by this MR - happens on `milestones#new` as well)
- [x] Don't use the panel for the created token
- [x] Use a normal flash for "Your new personal access token has been created"
- [x] Show the input (with the token) below it full width.
- [x] Put the "Make sure you save it - you won't be able to access it again." message near the input
- [x] Have the input highlight all on single click
- [x] Update screenshots
- [x] Merge master in + conflicts
- [x] Assign to @jschatz1 again
- [x] Respond to @jschatz1's comments
- [x] No button for clipboard, only link
- [x] text-danger
- [x] highlight fade on that area where the token was created
- [x] Make sure [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/d754d99179f1ffe846fcc1d8e858163b39efc5dc/builds) is green
- [x] Assign to @jschatz1
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/faa0e3f7580bc38d4d12916b4589c64d6c2678a7/builds) to pass
- [x] Respond to @DouweM's feedback
- [x] move the redirect_to out of the if/else
- [x] certificate -> token
- [x] datepicker back to text field
- [x] combine the get_user_from_private_token and get_user_from_personal_access_token methods in ApplicationController
- [x] combine the get_user_from_private_token and get_user_from_personal_access_token methods in `lib/api/helpers`
- [x] don't need the new constants
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/9d7cda3ddce52baad9618466a5d00319b333be57/builds) to pass
- [ ] Wait for merge
# Screenshots
See merge request !3749
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
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
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.
Added authentication service for docker registry
This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.
I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?
What do you think @jacobvosmaer @sytses @marin?
cc @marin
See merge request !3787
Rémy CoutableandRobert Speicher
Yorick PeterseandRobert Speicher
Douwe MaanandRobert Speicher
Kamil TrzcinskiandValery Sizov
Douwe Maan
David AlexanderandRémy Coutable
Douglas Barbosa Alexandre
Paco GuzmanandYorick Peterse
Rui AndersonandRémy Coutable
Sean McGivern
Thijs WoutersandAlfredo Sumaran
Timothy Andrew
Z.J. van de Weg
Stan Hu
Josh Frye
Grzegorz Bizon
Fatih Acet
Andrei Gliga
DJ Mountney