- 01 9月, 2017 3 次提交
-
-
由 Zeger-Jan van de Weg 提交于
Given the user can soon have multiple config sources for CI, we now store what type at the time of the pipeline run we chose. This will give us insight into what triggered the new pipeline so we can display it to the enduser.
-
由 Zeger-Jan van de Weg 提交于
-
由 Zeger-Jan van de Weg 提交于
Behind an application setting, which defaults to false, this commit implements the implied CI/CD config. Which means that in the case we can't find the `.gitlab-ci.yml` on the commit we want to start a pipeline for, we fall back to an implied configuration. For now the Bash template has been copied to `Auto-Devops.gitlab-ci.yml` so the tests actually work. Fixes #34777
-
- 31 8月, 2017 12 次提交
-
-
由 Sean McGivern 提交于
The initializers including this were doing so at the top level, so every object loaded after them had a `current_application_settings` method. However, if someone had rack-attack enabled (which was loaded before these initializers), it would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't have that method. To fix this: 1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need `Object.new.current_application_settings` to work. 2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it like that in several places. 3. Change the initializers to use that new form.
-
由 Tiago Botelho 提交于
-
由 Grzegorz Bizon 提交于
-
由 Zeger-Jan van de Weg 提交于
In this instance its subgroups, and given we can't deploy it, we shouldn't allow it to be shown. Fixes gitlab-org/gitlab-ce#34864
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Kim "BKC" Carlbäcker 提交于
- `Gitlab::Shell.fetch_remote` now takes a `Gitlab::Git::Repository` instead
-
由 Clement Ho 提交于
-
由 Marc Siegfriedt 提交于
-
由 Rubén Dávila 提交于
-
由 Mike Greiling 提交于
[ci-skip]
-
由 Mike Greiling 提交于
-
- 30 8月, 2017 13 次提交
-
-
由 Filipa Lacerda 提交于
-
由 Filipa Lacerda 提交于
-
由 Lin Jen-Shin 提交于
-
由 Yorick Peterse 提交于
This ensures the issues/MR cache of the sidebar is only updated when the state or confidential flags changes, instead of changing this for every update.
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
由 Hiroyuki Sato 提交于
-
由 kushalpandya 提交于
-
由 kushalpandya 提交于
-
由 Mark Fletcher 提交于
* Predefined variable represents the username of the GitLab user that started a build
-
由 Mark Fletcher 提交于
* Predefined variable represents the name of the GitLab user that started a build
-
由 blackst0ne 提交于
-
由 blackst0ne 提交于
-
- 29 8月, 2017 12 次提交
-
-
由 Robert Schilling 提交于
-
由 Lin Jen-Shin 提交于
So it's more clear what could happen. Also add more tests about the behaviour.
-
由 Travis Miller 提交于
-
由 Travis Miller 提交于
-
由 Filipa Lacerda 提交于
-
由 Phil Hughes 提交于
Closes #36698
-
由 Yorick Peterse 提交于
This adds a bunch of checks to migrations that may create or drop triggers. Dropping triggers/functions is done using "IF EXISTS" so we don't throw an error if the object in question has already been dropped. We now also raise a custom error (message) when the user does not have TRIGGER privileges. This should prevent the schema from entering an inconsistent state while also providing the user with enough information on how to solve the problem. The recommendation of using SUPERUSER permissions is a bit extreme but we require this anyway (Omnibus also configures users with this permission). Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36633
-
由 Hiroyuki Sato 提交于
-
由 Maxim Rydkin 提交于
-
由 Maxim Rydkin 提交于
-
由 Maxim Rydkin 提交于
-
由 Maxim Rydkin 提交于
-