gitlab-org--gitlab-foss/spec/factories/repository_languages.rb

# frozen_string_literal: true

FactoryBot.define do
  factory :repository_language do
    project
    programming_language
    share { 98.5 }
  end
end
Add frozen_string_literal to spec/factories Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758 2019-07-25 01:11:48 -04:00			`# frozen_string_literal: true`

Add repository languages for projects Our friends at GitHub show the programming languages for a long time, and inspired by that this commit means to create about the same functionality. Language detection is done through Linguist, as before, where the difference is that we cache the result in the database. Also, Gitaly can incrementaly scan a repository. This is done through a shell out, which creates overhead of about 3s each run. For now this won't be improved. Scans are triggered by pushed to the default branch, usually `master`. However, one exception to this rule the charts page. If we're requesting this expensive data anyway, we just cache it in the database. Edge cases where there is no repository, or its empty are caught in the Repository model. This makes use of Redis caching, which is probably already loaded. The added model is called RepositoryLanguage, which will make it harder if/when GitLab supports multiple repositories per project. However, for now I think this shouldn't be a concern. Also, Language could be confused with the i18n languages and felt like the current name was suiteable too. Design of the Project#Show page is done with help from @dimitrieh. This change is not visible to the end user unless detections are done. 2018-06-06 07:10:59 -04:00			`FactoryBot.define do`
			`factory :repository_language do`
			`project`
			`programming_language`
Add latest changes from gitlab-org/gitlab@master 2019-10-01 20:06:26 -04:00			`share { 98.5 }`
Add repository languages for projects Our friends at GitHub show the programming languages for a long time, and inspired by that this commit means to create about the same functionality. Language detection is done through Linguist, as before, where the difference is that we cache the result in the database. Also, Gitaly can incrementaly scan a repository. This is done through a shell out, which creates overhead of about 3s each run. For now this won't be improved. Scans are triggered by pushed to the default branch, usually `master`. However, one exception to this rule the charts page. If we're requesting this expensive data anyway, we just cache it in the database. Edge cases where there is no repository, or its empty are caught in the Repository model. This makes use of Redis caching, which is probably already loaded. The added model is called RepositoryLanguage, which will make it harder if/when GitLab supports multiple repositories per project. However, for now I think this shouldn't be a concern. Also, Language could be confused with the i18n languages and felt like the current name was suiteable too. Design of the Project#Show page is done with help from @dimitrieh. This change is not visible to the end user unless detections are done. 2018-06-06 07:10:59 -04:00			`end`
			`end`