- 18 Oct, 2016 1 commit
-
-
Kamil Trzcinski authored
-
- 03 Oct, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Kamil Trzcinski authored
-
- 30 Sep, 2016 2 commits
-
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
- 29 Sep, 2016 1 commit
-
-
Robert Speicher authored
This was brought over during the CI merge and already exists at `lib/gitlab/version_info.rb`.
-
- 20 Sep, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
- 19 Sep, 2016 4 commits
-
-
Kamil Trzcinski authored
-
Grzegorz Bizon authored
-
Kamil Trzcinski authored
-
Grzegorz Bizon authored
-
- 15 Sep, 2016 1 commit
-
-
Kamil Trzcinski authored
-
- 13 Sep, 2016 2 commits
-
-
Tomasz Maczukin authored
-
Kamil Trzcinski authored
Use a permissions of user to access all dependent projects from CI jobs (this also includes a container images, and in future LFS files)
-
- 07 Sep, 2016 11 commits
-
-
Kamil Trzcinski authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
Katarzyna Kobierska authored
-
- 05 Sep, 2016 1 commit
-
-
Jacob Vosmaer authored
-
- 29 Aug, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 24 Aug, 2016 1 commit
-
-
Stan Hu authored
Closes #21043
-
- 17 Aug, 2016 1 commit
-
-
Yorick Peterse authored
GitLab Performance Monitoring is now able to track custom events not directly related to application performance. These events include the number of tags pushed, repositories created, builds registered, etc. The use of these events is to get a better overview of how a GitLab instance is used and how that may affect performance. For example, a large number of Git pushes may have a negative impact on the underlying storage engine. Events are stored in the "events" measurement and are not prefixed with "rails_" or "sidekiq_", this makes it easier to query events with the same name triggered from different parts of the application. All events being stored in the same measurement also makes it easier to downsample data. Currently the following events are tracked: * Creating repositories * Removing repositories * Changing the default branch of a repository * Pushing a new tag * Removing an existing tag * Pushing a commit (along with the branch being pushed to) * Pushing a new branch * Removing an existing branch * Importing a repository (along with the URL we're importing) * Forking a repository (along with the source/target path) * CI builds registered (and when no build could be found) * CI builds being updated * Rails and Sidekiq exceptions Fixes gitlab-org/gitlab-ce#13720
-
- 11 Aug, 2016 1 commit
-
-
Kamil Trzcinski authored
This change simplifies a Pipeline processing by introducing a special new status: created. This status is used for all builds that are created for a pipeline. We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped). This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled. This also allows us to visualise a full pipeline (with created builds). This also removes an after_touch used for updating a pipeline state parameters. Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.
-
- 08 Aug, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 27 Jul, 2016 1 commit
-
-
Ahmad Sherif authored
-
- 20 Jul, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 19 Jul, 2016 4 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Grzegorz Bizon authored
-