VSTS构建包括所有以前的提交作为关联的更改 [英] VSTS builds includes all previous commits as associated changes

查看:59
本文介绍了VSTS构建包括所有以前的提交作为关联的更改的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我遇到一个问题,使我以前的所有提交都显示为每个新构建中的关联更改.我相信问题与使用通配符分支模式自动触发构建定义有关.我会使用模式'release/*'在分支名称上的所有提交上触发我们的发布版本.我们软件的每个生产版本都从一个新的发行分支开始,该分支具有以下命名约定"release/1","release/2"等,其编号与我们发行的软件版本相匹配.

I have an issue that makes all my previous commits show as associated changes in each new build. I believe the issue is related to the automatic triggering of the build definition using a wildcard branch pattern. I trigger our release builds on any commits on a branch name with the pattern 'release/*'. Each production release of our software starts with a new release branch with the following naming convention 'release/1', 'release/2', etc. where the number matches our released software version.

问题在于,当运行"release/2"构建时,相关联的更改将显示所有导致"release/2"的提交,包括导致"release/1"的提交.每个新版本都将继续执行此操作.

The problem is that when the 'release/2' build gets ran, the associated changes show all commits that lead up to 'release/2' including the commits that led up to 'release/1'. This continues with every new release.

我认为它应该起作用的方式是仅显示当前版本和先前成功版本之间发生的更改.

I thought the way that it was supposed to work, was to only show the changes that occurred between the current build and the previous successful build.

任何对此问题的见解将不胜感激.

Any insight into this issue would be appreciated.

重现此问题的步骤:

  1. 在VSTS中,创建一个git repo w/添加自述文件
  2. 创建新的构建定义(空),将获取源代码"步骤设置为您刚刚创建的存储库,并将分支设置为master
    • 转到选项并将自动链接此版本中的新作品"设置为启用
    • 转到触发器">持续集成">触发器状态">已启用">分支过滤器">将分支规范"设置为发布/*"(不包括单引号)
  1. In VSTS create a git repo w/ add readme
  2. Create new build definition (empty), set 'Get Sources' step to the repo you just created and the branch to master
    • go to options and set 'Automatically link new work in this build' to enabled
    • go to 'Triggers' > Continuous Integration > Trigger Status > Enabled > Branch Filters > set Branch specification to 'release/*' (excluding single quotes)

创建第一个发行分支

  • git checkout -b release/1
  • 修改ver.txt(我只是增加值)
  • git commit -am "Updated to version 1"
  • git push origin release/1
  • 一旦将此分支推送到服务器,应触发
  • build
  • 构建完成后,查看构建摘要>关联的更改,请注意,此新存储库的所有提交都已列出
  • 将发布分支合并回master
    • git checkout master
    • git merge release/1
    • git branch -d release/1
    • git push origin -d release/1
    • git checkout -b release/1
    • make modifications to ver.txt (I just increment the value)
    • git commit -am "Updated to version 1"
    • git push origin release/1
    • build should be triggered once this branch is pushed to the server
    • Once build is finished, view build Summary > Associated changes, notice that all commits for this new repo are listed
    • Merge release branch back into master
      • git checkout master
      • git merge release/1
      • git branch -d release/1
      • git push origin -d release/1

      创建第二个发行分支

      • git checkout -b release/2
      • 修改ver.txt(我只是增加值)
      • git commit -am "Updated to version 2"
      • git push origin release/2
      • 一旦将此分支推送到服务器,应触发
      • build
      • git checkout -b release/2
      • make modifications to ver.txt (I just increment the value)
      • git commit -am "Updated to version 2"
      • git push origin release/2
      • build should be triggered once this branch is pushed to the server

      这时,在查看最新版本的关联更改时,您会看到它继续累积存储库的整个历史记录

      At this point when looking at the latest builds' Associated changes you will see that it continues to cumulate the entire history of the repository as opposed to just the commits between the current build and the last successful build despite the fact that it is the same build definition being ran

      推荐答案

      它也基于源代码,而不仅仅是构建,因此对于release/2,它将当前构建与release/2分支源的上次成功构建进行比较,因此它包含了release/1中的提交.

      It is also based on the source, not just build, so regarding release/2, it compares current build with last successful build of the release/2 branch source, so it includes the commit in release/1.

      我建议您可以将合并请求中的更改与成功的构建合并,并检查此构建中的更改. (分支机构)

      I recommend that you can merge changes through Pull Request with a successful build, and check the changes in this build. (Branch policy)

      这篇关于VSTS构建包括所有以前的提交作为关联的更改的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆