Reload the schema before restoring a database backup
If a user tries to downgrade and restore after a failed upgrade,
the database may still contain newer tables. Reload the older
schema before restoring the database to avoid future upgrade
problems. Also, add a rake task to help users add migration
versions to the database so it's easier to recover from these
errors if they do occur. Fixes#13419
See merge request !2807
GitLab intro docs
Related to https://gitlab.com/gitlab-org/marketing_monthly_release/issues/1
---
Need refactor:
- Create a new project
- Create a new group
- Create a new issue
- Assign labels to issues
- Use milestones as an overview of your project's tracker
- Fork a project and contribute to it
- Create a new merge request
- Automatically close issues from merge requests (include GitLab.com pattern)
- GitLab CI quick start guide (make it easier to follow)
Moved to https://gitlab.com/gitlab-org/gitlab-ce/issues/8068
See merge request !3225
Soft delete issuables
Fixes#2489
What still needs to happen: research on the indexes, the gem suggests a [lot of changes](https://github.com/rubysherpas/paranoia#about-indexes) though this is probably a good idea to discuss and I'm unsure on the impact of an omnibus upgrade as I suspect creating about 10 new indexes has a large impact on the downtime.
TODO:
- [x] Also group owners can ***soft*** delete
- [x] Button should be hidden
See merge request !2982
CI: Add 'triggers' keyword to 'only' and 'except' lists to allow control over when triggers cause builds to run
Currently, the `only` and `except` keywords in `.gitlab-ci.yml` only accept ref names or the special `branches` and `tags` keywords. However, these are primarily useful when controlling how repository activity affects the creation of builds. In my case, instead of building on every commit, I'd like to use the following logic:
- If the repository is tagged, do a build.
- Any other normal commits should not cause a build.
- If a build is triggered via the API, always create one for the specified ref.
From what I can tell, this isn't possible via the existing YAML syntax. In this MR, I introduce a new keyword `triggers` that goes along with `branches` and `tags`. I can implement the logic above using the following job configuration:
```yaml
only:
- tags
- triggers
```
I updated the tests and documentation to reflect this and everything seems to pass.
See merge request !3230
Use gitlab-workhorse 0.7.1
A small extra defense against interrupted git raw responses. Nice to
have in 8.6 because we introduce /raw/ caching; it would be
unfortunate if incorrect (truncated) responses got cached.
See merge request !3330
Add information about `image` and `services` field at `job` level in the `.gitlab-ci.yml` documentation
Fixes#14366
/cc @tmaczukin @ayufan @axil
See merge request !3277
Add note in upgrade guide to choose the correct version tag
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/3448
@rspeicher I'm assigning to you since as a release manager you should know better. Let's keep it in this guide for now and then start copying it in the future ones.
See merge request !2284
External Users
The user has the rights of a public user execpt it can never create a project, group, or team. Also it cant view internal projects.
Partially fix for both #4009 and #13938 (except the LDAP sync or a pattern to detect external users)
See merge request !3171
Fix requirements.md link and improve PostgreSQL commands
- Point requirements.md link to the correct location
- Link to gitlab installation.md document instead of github
- Use psql command switch to run specified SQL commands for creation of user and database permissions.
- Instead of requiring a comment like `# Do not type the 'template1=#', this is part of the prompt` it may be easier to just use the command switch with `psql` to execute the SQL commands.
*forgot [ci skip] :(*
See merge request !3176
CSS style guide
Working towards what was discussed in #13552, this adds the [SCSS Linter gem](https://github.com/brigade/scss-lint) for style guide conformity in CI.
TODO:
- [x] Agree on and write SCSS Style Guide Documentation.
- [x] Document the `scss-lint` config file.
- [x] Figure out how best to run this in CI, right now it's taking longer than I would think it should.
- [x] Use CSSComb for auto-correction (Maybe just include a CSSComb config file and have developers run the node package manually if they're interested in using it?).
My logic for not using CSSComb in the first place is that, AFAIK, we don't currently require Node/NPM, even in the dev environment. Maybe I'm wrong about that? `scss-lint` is a Ruby implementation of a similar concept, but it doesn't include autocorrect.
Is there a way we can run get GitLab CI to run `scss-lint` without having to put together the full GitLab application? Seeing as it's just static analysis, it seems like a waste of time/resources.
/cc @jschatz1 @rspeicher
See merge request !3069
Cleanup Ci::Commit, Ci::Build and CommitStatus views
This MR tries to do first sweep of cleanups to Ci::Commit and
Ci::Build objects removing all view-related functions and fixing the
API from other side.
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/6046
See merge request !2760
Bring from EE: Share Project with Group
- [x] Models and migrations
- [x] Logic, UI
- [x] Tests
- [x] Documentation
- [x] Share with group lock
- [x] Api feature
- [x] Api docs
- [x] Api tests
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
For #12831
cc @DouweM @rspeicher @vsizov
See merge request !3186
- Remove all view related methods from Ci::Build and CommitStatus
- Remove unused Ci::Commit and Ci::Build methods
- Use polymorphism to render different types of CommitStatus
Rémy Coutable
Nitin Madhok
Robert SpeicherandRémy Coutable
Achilleas PipinellisandRémy Coutable
Douwe MaanandRémy Coutable
Kamil TrzcińskiandRémy Coutable
Robert Schilling
Mark Pundsack
Jacob Vosmaer
Daniel CarraroandRémy Coutable
Chris Wilson
Douwe Maan
Zeger-Jan van de Weg
Jacob Schatz
Jeroen van Baarsen
connorshea
Dmitriy Zaporozhets
Jasper Denkers