SonarQube использует неверный (?) запрос ElasticSearch для получения ScmAccountToUser

Я запускаю SonarQube 5.3 в Windows с серверной частью MSSQL.

При создании новых задач SonarQube запрашивает свой пользовательский индекс ElasticSearch, чтобы получить логин автора для информации «git виноват» в строке, представляющей проблему.

В /server/sonar-server/src/main/java/org/sonar/server/computation/issue/IssueAssigner.java происходит следующее:

=> Информация «git виноват» возвращает автора затронутой строки, в моем примере (анонимно):

steve smith@ca5553f7-9c36-c34d-916b-b330600317e9

=> Это значение ищется в ScmAccountToUser, который лениво запрашивает индекс «пользователей» ElasticSearch. Я добавил некоторые отладочные данные для печати запроса ES, а именно:

{
  "size": 3,
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      },
      "filter": {
        "bool": {
          "must": {
            "term": {
              "active": true
            }
          },
          "should": [
            {
              "term": {
                "login": "steve smith@ca5553f7-9c36-c34d-916b-b330600317e9"
              }
            },
            {
              "term": {
                "email": "steve smith@ca5553f7-9c36-c34d-916b-b330600317e9"
              }
            },
            {
              "term": {
                "scmAccounts": "steve smith@ca5553f7-9c36-c34d-916b-b330600317e9"
              }
            }
          ]
        }
      }
    }
  }
}

Этот запрос возвращает 0 результатов.

Напротив, когда я перечисляю весь индекс, я получаю обращение, которое обычно должно соответствовать этому пользователю:

{ -
  "took": 4,
  "timed_out": false,
  "_shards": { -
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": { -
    "total": 39,
    "max_score": 1,
    "hits": [ -
      { -
        // snip
      },
      // snip
      { -
        "_index": "users",
        "_type": "user",
        "_id": "steve.smith",
        "_score": 1,
        "_source": { -
          "createdAt": 1442988141642,
          "name": "Steve Smith",
          "active": true,
          "login": "steve.smith",
          "scmAccounts": [ -
            "
",
            "steve smith@ca5553f7-9c36-c34d-916b-b330600317e9
",
            "steve.smith@ca5553f7-9c36-c34d-916b-b330600317e9
"
          ],
          "email": "[email protected]",
          "updatedAt": 1450088380632
        }
      },
      // snip
    ]
  }
}

Эта проблема в настоящее время не позволяет моему экземпляру SonarQube автоматически назначать множество проблем. Я нахожусь в процессе выяснения, когда и как это сломалось, так как некоторые автоматические назначения ранее были успешными.

Это ошибка в запросе или в данных? Можно ли как-то обойти эту проблему?


person ThePadawan    schedule 22.04.2016    source источник
comment
Каково отображение поля scmAccounts? Если это не строковое поле not_analyzed, то причина в этом.   -  person Val    schedule 22.04.2016
comment
Сопоставление действительно указывает: // ... scmAccounts: { - index: not_analyzed, type: string }, //... которое отличается от других полей, например. логин: логин: { - index: not_analyzed, тип: строка, fields: { - ngrams: { - search_analyzer: search_ngrams, index_analyzer: index_ngrams, type: string } } }, Значит, это неправильная конфигурация сопоставления? Я уже полностью восстановил индекс, поэтому проблема продолжает появляться.   -  person ThePadawan    schedule 22.04.2016
comment
основной причиной, по-видимому, является пробел в учетной записи scm. Вы подтверждаете?   -  person Simon Brandhof - SonarSource    schedule 26.04.2016
comment
@SimonBrandhof-SonarSource Проблема, похоже, заключается в новых строках в начале и конце scmAccounts. Я удалил и снова добавил учетную запись steve smith@... scm в графическом интерфейсе SonarQube, и теперь данные ES больше не содержат этих новых строк, и запрос выполнен успешно. Я скопировал таблицу пользователей из предыдущего экземпляра SonarQube с версией 5.2 — это может быть проблемой совместимости. Я попытаюсь повторно добавить учетные записи SCM вручную для всех пользователей и сообщу о результатах. Это также объясняет, почему 10 % назначений выполняются успешно — этим исполнителям были добавлены учетные записи SCM вручную.   -  person ThePadawan    schedule 26.04.2016
comment
@SimonBrandhof-SonarSource Удаление новых строк решило эту проблему. Я добавлю ответ.   -  person ThePadawan    schedule 27.04.2016


Ответы (1)


Оказывается, проблема была из-за новых строк в записях поля «scmAccounts».

При повторном добавлении учетных записей SCM вручную в пользовательском интерфейсе SonarQube эти поля были обновлены до

"scmAccounts": 
[ -
            "steve smith@ca5553f7-9c36-c34d-916b-b330600317e9",
            "steve.smith@ca5553f7-9c36-c34d-916b-b330600317e9"
],

, после чего запрос был выполнен успешно, а назначение задачи выполнено успешно.

Новые строки попали в поля в первую очередь потому, что я вручную восстановил таблицу «users» на SQL-сервере из резервного SQL-скрипта INSERT.

person ThePadawan    schedule 27.04.2016
comment
Хорошо знать. Кто ввел новые строки? Вы или инструмент резервного копирования SQLServer? В последнем случае SonarQube должен покрыть этот крайний случай и очистить учетные записи SCM при индексировании в Elasticsearch. - person Simon Brandhof - SonarSource; 27.04.2016
comment
@SimonBrandhof-SonarSource Я выполнил табличный экспорт БД в сценарии .sql INSERT (используя MSSQL Server 2012), которые экспортировали новые строки. Может быть проблема из-за окончаний строк Windows - я могу отправить вам (цензурированный) файл users.sql, чтобы воспроизвести проблему. Пожалуйста, свяжитесь с нами. - person ThePadawan; 27.04.2016
comment
Спасибо, но это довольно легко воспроизвести. Поскольку проблема заключается в резервной копии базы данных, в SonarQube ничего не нужно исправлять. - person Simon Brandhof - SonarSource; 28.04.2016