Как я могу использовать GitHub API (octokit) для фильтрации коммитов, которые сразу влияют на главную ветку?

Я автоматизирую семантическое управление версиями с помощью TeamCity и Github и пытаюсь найти способ подсчета коммитов, которые напрямую влияют на основную ветку.

Вероятно, лучше всего это объясняется на этом аннотированном скриншоте из Git-Extensions. Я хочу автоматически вычислить номера версий в стрелках:

скриншот git-extensions

Я использую ruby ​​и octokit для запросов к GitHub API как части моего процесса сборки. Номер основной и дополнительной версии увеличивается вручную, когда фиксация или слияние квалифицируются как основная/дополнительная версия, поэтому псевдокод в основном выглядит следующим образом:

  1. найти фиксацию, соответствующую major.minor.0
  2. подсчитывать каждую фиксацию, начиная с major.minor.0, которая изменила состояние основной ветки
  3. установите версию патча на commits.count

Проблема, с которой я столкнулся, заключается в том, что если я просто подсчитываю коммиты для master, каждый раз, когда принимается запрос на вытягивание, счетчик коммитов увеличивается на n+1, где n количество коммитов, сделанных в ветке. Это будет работать, но это... неэлегантно. Да, я понимаю, что когда вы принимаете запрос на вытягивание, вы фактически принимаете всю историю этой ветки как часть вашей «главной» истории, но для целей управления версиями это не имеет значения.

Кто-нибудь знает, как я могу фильтровать коммиты через API GitHub, чтобы узнать, повлияла ли фиксация непосредственно на master в момент ее создания, или есть какая-то причина, по которой это на самом деле невозможно?

Спасибо!


git github github-api semantic-versioning octokit
person Dylan Beattie    schedule 31.10.2013    source источник
comment
Это отличный вопрос. Не уверен, каким будет лучший подход, и может случиться так, что это невозможно сделать для некоторых случаев. Например, если в этом графе коммитов, который у вас есть в вопросе, не было никаких ссылок на ветки, кроме master, вы не знали бы, где размещать стрелки версий, потому что вы не знали бы, какие коммиты были на master. И такая ситуация может случаться часто, потому что после того, как кто-то сольет ветку в мастер, он, вероятно, удалит ее. Итак, все, что у вас осталось, — это большой сложный граф с одной ветвью (=мастер).   -  person Ivan Zuzak    schedule 01.11.2013
comment
Итак, в конце концов, проблема в том, что ветка git — это не что иное, как указатель на один коммит. Вы не знаете, какие ветки указывали на какую-то фиксацию в прошлом. Вы можете только сказать, доступен ли какой-либо коммит из определенной ветки (= коммит).   -  person Ivan Zuzak    schedule 01.11.2013

Ответы (1)


arrow_upward
0
arrow_downward

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

var filter = new PullRequestRequest() { State = ItemState.Closed }; //for my example, I filtered the pull-requests that are closed
var prs =await client.Repository.PullRequest.GetAllForRepository(Owner,Name,filter);
foreach(var pr in prs){
var prs2 = await client.Repository.PullRequest.Commits (Owner, Name, pr.Number);
}

После этого вы получите атрибут prs2 Sha и сохраните его в списке. Затем вы получаете все коммиты репо.

var commits = await client.Repository.Commit.GetAll (Owner, Name);

Наконец, вы сравните список с sha из коммитов в пулл-реквестах и ​​исключите их из списка, который содержит все коммиты репо. Таким образом, останутся только те коммиты, которых нет в пулл-реквесте. При желании вы можете проверить, являются ли эти коммиты коммитами слияния (коммитами, которые объединяют запрос на вытягивание другого участника), и также исключить их.

person Dimitris Tim    schedule 11.05.2016