我们目前正在开发一个具有多个并行开发流的应用程序。我们有一个Jenkins工作来构建每个流/版本。因此，Job-A可能正在构建版本1.1，而Job-B可能正在构建版本1.2。
我认为最好在每个版本中共享内部版本号，这样如果Job-A以内部版本号125运行，如果Job-B下次运行，它将以内部版本号126运行。我认为这是最好的策略是这是一个Android应用程序，每次提交到Google Play时都需要增加versionCode参数。我们使用Jenkins内部版本号作为versionCode值。
有没有办法配置Jenkins在多个作业中共享内部版本号？或者，有没有人想出更好的解决方案来解决这个问题？
答案 0 :(得分：5)
简短回答使用时间戳或手动设置versionCodes，在不需要时将内容保留在CI服务器之外。或者强制jenkins建立数字。
长答案我喜欢jenkins负责自动化某些也可以自行运行的东西。因此，如果我不需要jenkins进行设置，我也很高兴。
此外，如果你使用2个分支，你可能会以随机顺序提交它们。试图在某些方面将工作联系在一起似乎是一个不必要的麻烦，以后可能会出现问题。例如。如果版本2.0现在构建和QAed，只是等待正确的发布日期和营销团队完成其工作，但是你需要在那之后发布v1.1.1快速修复？根据您选择的解决方案，您可能需要触发一些重建以强制执行versionCode bump。新建，新QA？
您对versionCode的真正要求是它高于之前的版本。
来自http://developer.android.com/guide/topics/manifest/manifest-element.html
android：versionCode内部版本号。
使用此号码 只是为了确定一个版本是否比另一个版本更新， 数字越大表示更新的版本。这不是 显示给用户的版本号;该号码由versionName设置 属性。该值必须设置为整数，例如“100”。您可以 你可以定义它，只要每个连续的版本都有 更高的数字。例如，它可以是内部版本号。或者你可以 通过编码将“x.y”格式的版本号转换为整数 低位和高位16位分别为“x”和“y”。或者您 每次新版本时，可以简单地将数字增加一个 释放。
所以这里有2个解决方案：
手动撞击。在我们的项目中，我使用一些sed脚本在发布之前自动化构建号的碰撞。由于我还需要手动更改一些内容，例如versionName前缀，在开发期间禁用/启用调试模式等，我手动运行bumpversion脚本，以便我的分支中的下一个构建具有适当的版本和versionCode编号。注意我在versionName中使用jenkins内部版本号。如果为v2选择足够大的versionCode凹凸，此解决方案可防止您在v2准备就绪后需要将1.1.1问题解决。
另一个更自动但仍然简单的解决方案是使用时间戳之外的东西。格式YYMMDDHHSS足够好一个整数（<2 ^ 31），并且很可能无论你接下来要发布的版本是在前一个版本之后准备的，而不是在同一分钟之内。所以基本上当你构建v1.1时，它会得到例如1308131600并且如果你在获得1308131601之后的那一刻建立v1.2（这显然不能帮助你对抗v1.1.1 / v2场景）
以下是生成/更新versionCode Auto increment version code in Android app的脚本的一些想法。
jenkins方式
现在，如果您仍然希望jenkins负责，一个简单的解决方案是使用类似https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin的内容，并将每个分支作业配置为具有足够大的前缀以确保不会发生冲突。设置仍然非常简单。
E.g。
答案 1 :(得分：0)
您可以查看multijob插件，您可以在其中添加多个参数化作业到包含的作业
https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin
您还可以查看工件存档Archive the artifacts in hudson/jenkins，然后再选择文件
答案 2 :(得分：0)
我还没有尝试过，但我正在考虑继续使用构建计算机和每个作业，用符号链接将nextBuildNumber文件替换为单个文件。什么可能出错。好吧，并发访问可能是一个问题。如果Jenkins从头开始重新创建文件，可能会出现问题，即使用remove和create，而不是像往常一样打开它。
答案 3 :(得分：-3)
@coffeebreaks提供了很好的响应，但我们最终编写了一个自定义插件，如果作业名称具有匹配的前缀，则允许作业共享内部版本号。