GitLab CI Yaml template dropdown
## What does this MR do?
Make it possible to select a dropdown for an easy start with GitLab CI.
## What are the relevant issue numbers?
Closes#17521
## TODO
- [ ] Backend
- [x] CHANGELOG item
- [x] Fix rubocop failure
- [x] API Support
- [x] New tests
- [x] Add disclaimer to the top of the gitlab-ci.yml
- [ ] Frontend
- [x] New tests
See merge request !4411
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
Implement custom notification level options
part of #12758
See merge request !4389
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
Added API endpoint for Sidekiq Metrics.
## What does this MR do?
It adds an API endpoint to gather metrics about Sidekiq, it's jobs, queues, and processes.
## Why was this MR needed?
There was no API endpoint for Sidekiq information.
## What are the relevant issue numbers?
Fixes#7171
## 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
- [x] Tests
- [x] Added for this feature/bug
- [x] All builds are passing
See merge request !4653
* commit 'ca3c5c295ed653b483fe81c3918ffe60f46666b9':
Let contributors know where to start
Ensure branch cleanup regardless of whether the import process succeeds
Fix failing todo tests
Reorder the todos because the use of the project finder attempts to order them differently
Update target todo test to use a public project
Use the project finder in the todos finder to limit todos to just ones within projects you have access to.
Move filtering todos by projects not pending deletion into a scope on the todo model
Reduce the filters on the todos joins project query by being explicit about the join
Ensure we don't show TODOS for projects pending delete
Fix deprecation warnings in spec/services/issues/bulk_update_service_spec.rb
Remove unused Issuable#is_assigned? method
fixup! Don't allow merges with new commits
fixup! Add `sha` parameter to MR accept API
Reduce Namespace queries in UserReferenceFilter
Added ReferenceFilter#nodes
Returning enums in ReferenceFilter#each_node
Don't allow merges with new commits
Add `sha` parameter to MR accept API
The `sha` parameter is optional, and when present, must match the
current HEAD SHA of the source branch. Otherwise, the API call fails
with a 409 Conflict and a message containing the current HEAD for the
source branch.
Also tidy up some doc wording.
Restrict starred projects to viewable ones
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
Closes#17249.
See merge request !4108
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
- Fix naming of API::CommitStatuses
- Ensure we use require_dependency instead of require
- Ensure the namespace is right in lib/api/api.rb, otherwise, we
might require Grape::API::Helpers which defines the `#params` method.
This is to avoid requiring a file multiple times and getting an "Already
initialized constant" error.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Jacob SchatzandRobert Speicher
Rémy CoutableandRobert Speicher
Robert SpeicherandRobert Speicher
Douwe MaanandRobert Speicher
Achilleas PipinellisandRobert Speicher
Kamil Trzcinski
Douglas Barbosa Alexandre
Stan Hu
Rui AndersonandRémy Coutable
Z.J. van de Weg
Sean McGivern
Felipe Artur
Grzegorz BizonandRobert Speicher
Connor Shea
Fatih Acet
Gabriel Mazetto
Ahmad Sherif