2019-04-11 12:17:24 +00: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 11:10:59 +00:00
|
|
|
require 'spec_helper'
|
|
|
|
|
2020-06-24 15:08:50 +00:00
|
|
|
RSpec.describe Projects::DetectRepositoryLanguagesService, :clean_gitlab_redis_shared_state do
|
2020-01-10 09:07:49 +00:00
|
|
|
let_it_be(:project, reload: true) { create(:project, :repository) }
|
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 11:10:59 +00:00
|
|
|
|
2019-05-04 09:11:06 +00:00
|
|
|
subject { described_class.new(project) }
|
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 11:10:59 +00:00
|
|
|
|
|
|
|
describe '#execute' do
|
|
|
|
context 'without previous detection' do
|
|
|
|
it 'inserts new programming languages in the database' do
|
|
|
|
subject.execute
|
|
|
|
|
|
|
|
expect(ProgrammingLanguage.exists?(name: 'Ruby')).to be(true)
|
|
|
|
expect(ProgrammingLanguage.count).to be(4)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'inserts the repository langauges' do
|
|
|
|
names = subject.execute.map(&:name)
|
|
|
|
|
|
|
|
expect(names).to eq(%w[Ruby JavaScript HTML CoffeeScript])
|
|
|
|
end
|
2019-03-20 17:23:23 +00:00
|
|
|
|
|
|
|
it 'updates detected_repository_languages flag' do
|
|
|
|
expect { subject.execute }.to change(project, :detected_repository_languages).to(true)
|
|
|
|
end
|
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 11:10:59 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'with a previous detection' do
|
|
|
|
before do
|
|
|
|
subject.execute
|
|
|
|
|
|
|
|
allow(project.repository).to receive(:languages).and_return(
|
|
|
|
[{ value: 99.63, label: "Ruby", color: "#701516", highlight: "#701516" },
|
|
|
|
{ value: 0.3, label: "D", color: "#701516", highlight: "#701516" }]
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'updates the repository languages' do
|
|
|
|
repository_languages = subject.execute.map(&:name)
|
|
|
|
|
|
|
|
expect(repository_languages).to eq(%w[Ruby D])
|
|
|
|
end
|
2019-03-20 17:23:23 +00:00
|
|
|
|
|
|
|
it "doesn't touch detected_repository_languages flag" do
|
|
|
|
expect(project).not_to receive(:update_column).with(:detected_repository_languages, true)
|
|
|
|
|
|
|
|
subject.execute
|
|
|
|
end
|
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 11:10:59 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'when no repository exists' do
|
2020-01-10 09:07:49 +00:00
|
|
|
let_it_be(:project) { create(:project) }
|
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 11:10:59 +00:00
|
|
|
|
|
|
|
it 'has no languages' do
|
|
|
|
expect(subject.execute).to be_empty
|
|
|
|
expect(project.repository_languages).to be_empty
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|