| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
wrong SSH key.
|
| | |
|
| |
|
|
| |
creating a user with this username, and method name refactoring.
|
| |
|
|
| |
LFS Tokens
|
| | |
|
| |
|
|
| |
simplify external code.
|
| |
|
|
| |
`/lfs_authenticate` and added tests.
|
| |
|
|
| |
a 1 use only token.
|
| | |
|
| |
|
|
| |
- Required on the GitLab Rails side is mostly authentication and API related.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improve validity of spec/features/todos/todos_filtering_spec.rb
Previously, we were checking that a CSS selector string didn't have some
page-related content, which, of course it didn't.
Now we check against the actual content of the selector, we use a more
semantic selector, and we add an additional expectation for the text
that _should_ be there, as an additional sanity check.
See merge request !6356
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we were checking that a CSS selector string didn't have some
page-related content, which, of course it didn't.
Now we check against the actual content of the selector, we use a more
semantic selector, and we add an additional expectation for the text
that _should_ be there, as an additional sanity check.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update references to deprecated `repos_path` configuration key to avoid
## What does this MR do?
Update references to deprecated `repos_path` configuration key to avoid errors when updating GitLab from older versions
## Why was this MR needed?
Users were reporting errors when upgrading from GitLab 6.7
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1464
See merge request !6350
|
| | | |
| | |
| | |
| | | |
errors on updates from older versions
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Group similar builds
We group builds by removing from the builds name two numbers which are delimited by whitespace or colon:
* `name 0 1` => `name`
* `name 0:1` => `name`
* `name 0/1` => `name`
* `name 0:1 ruby` => `name ruby`
* `name 0/1 ruby` => `name ruby`
* `0 1 name ruby` => `name ruby`
* `0:1 name ruby` => `name ruby`
* `0/1 name ruby` => `name ruby`
See merge request !6242
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Trigger autosize update after template selection
## What does this MR do?
Triggers an autosize update after selecting an issue template.
The autosize plugin doesn't react to value changes and therefore doesn't automatically update when the user selects the template. This merge request adds it so that it detects if the editor the template selector is a jQuery object (not Ace editor) & then triggers the autosize event to allow the user to scroll the textarea.
## Screenshots (if relevant)
## What are the relevant issue numbers?
Closes #21982
See merge request !6282
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes #21982
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
doc/ci/quick_start/README: improve sentence about link to a Lint tool
## What does this MR do?
It improves the `doc/ci/quick_start/README.md` documentation.
## Are there points in the code the reviewer needs to double check?
The reviewer can check that there is no more **CI settings** menu and that the Lint tool can be accessed under **Pipelines > Pipelines** and **Pipelines > Builds**.
## Why was this MR needed?
Because the CI quick start documentation was not correct.
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
It is not a code change so I don't think the below criteria are relevant.
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
I didn't check if there was an issue for this.
See merge request !6301
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The link is now a button under **Pipelines > Pipelines** and **Pipelines > Builds**.
There is no more **CI settings** menu.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
doc/user/permissions: update option and menu names
## What does this MR do?
This fixes `doc/user/permissions.md` documentation.
## Are there points in the code the reviewer needs to double check?
The reviewer can check that the name of the option is now **Public pipelines** and that this option is in **Project Settings > CI/CD Pipelines**.
## Why was this MR needed?
Because the previous name of the option and of the menu had not been updated in `doc/user/permissions.md` when they were changed.
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
This is a documentation only MR, so I don't think it needs to pass all these acceptance criteria.
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
I don't know of any issue number.
See merge request !6302
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It looks like the option is now called **Public pipelines**
and the menu item is now **Project Settings > CI/CD Pipelines**.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixed add to tree button on mobile
## What does this MR do?
Fixes an issue with the width of the add to tree button on mobile.
This was caused by acde2e30b62ca7adaae2a7afd75f09f7a56be58e adding `100%` width for mobile.
## Screenshots (if relevant)
## What are the relevant issue numbers?
Closes #22128
See merge request !6339
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Closes #22128
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Fix the ordering of transition callbacks
Because pipeline status could be changed for the builds in the next
stages, if we process next stages first, the current build would be
out of synchronized, and would need a reload for that matter.
Alternatively, like what I did in this commit, we could process the
next stages later (by using `after_transition` rather than
`around_transition`), and complete what're doing for the current
build first. This way we don't have to reload because nothing is
out synchronized.
Note that since giving `false` in `after_transition` would halt the
callbacks chain, according to:
https://github.com/state-machines/state_machines-activemodel/blob/v0.4.0/lib/state_machines/integrations/active_model.rb#L426-L429
We'll need to make sure we're not returning false because we don't
intend to interrupt the chain.
This fixes #22010.
After this fix, both pipeline events and build events would only show
up once.
See merge request !6305
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6305#note_15230024
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The observed faulty state transition is probably hard to test,
because we need to hook into internal states to observe them.
Namely this:
07:30:16 | Build#ruby-2.2 enqueue: created -> pending
07:30:16 | Pipeline#32 enqueue: created -> pending
07:30:16 | Build#ruby-2.3 enqueue: created -> pending
07:30:16 | Build#ruby-2.2 run: pending -> running
07:30:16 | Pipeline#32 run: pending -> running
07:30:29 | Build#ruby-2.2 drop: running -> failed
07:30:29 | Pipeline#32 run: running -> running
07:30:29 | Build#ruby-2.3 run: pending -> running
07:30:30 | Pipeline#32 run: running -> running
07:30:57 | Build#gem:build skip: created -> skipped
07:30:57 | Pipeline#32 drop: running -> failed
07:30:57 | Build#gem:release skip: created -> skipped
07:30:57 | Pipeline#32 drop: failed -> failed
07:30:57 | Build#ruby-2.3 drop: running -> failed
07:30:57 | Pipeline#32 drop: running -> failed
^^^ Should be failed -> failed
However, the consequence of this, executing hooks twice would be
easy enough to observe. So we could at least test against this.
Keep in mind that if we ever changed how we execute the hooks
this won't be testing against faulty state transition.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This reverts commit 575dc2b0d78b2680d6e5bb43f293c98d378b8733.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Because pipeline status could be changed for the builds in the next
stages, if we process next stages first, the current build would be
out of synchronized, and would need a reload for that matter.
Alternatively, like what I did in this commit, we could process the
next stages later (by using `after_transition` rather than
`around_transition`), and complete what're doing for the current
build first. This way we don't have to reload because nothing is
out synchronized.
Note that since giving `false` in `after_transition` would halt the
callbacks chain, according to:
https://github.com/state-machines/state_machines-activemodel/blob/v0.4.0/lib/state_machines/integrations/active_model.rb#L426-L429
We'll need to make sure we're not returning false because we don't
intend to interrupt the chain.
This fixes #22010.
After this fix, both pipeline events and build events would only show
up once.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
'master'
Simplify the 'Implement design & UI elements' section in CONTRIBUTING
There's a nice documentation page in the gitlab-design page, so just link to it!
See merge request !6249
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Clean environment variables when running git hooks
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20977
See merge request !6344
|
| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / /
|/| | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Bump rubocop to 0.42.0
Also updates `.rubocop_todo.yml` for the latest cops.
See merge request !6354
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Allow flay and flog to fail for now
flay and flog started working somehow (despite #17858). Disabling them for now since the broken builds are impeding progress.
See merge request !6360
|
| | | |_|_|_|_|_|_|/ /
| |/| | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / /
|/| | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Ignore SVG whitelist code from flay
The SVG whitelist code was generated from table definitions, and simplifying it would actually make it harder to read.
See merge request !6361
|
