我在Azure DevOps中建立了一个Gradle构建,它在Azure DevOps git存储库中编译代码,然后将生成的JAR(作为Maven工件)发布到Azure Artifacts,如here所述。然后,其他Azure DevOps git存储库中的代码可以引用这些组件作为依赖项。对于这些组件的正式发行版(具有唯一的版本号),这很好,但是我还需要一种方法来使其在进行中的快照发行版中起作用。问题是我不能多次发布具有相同版本号(例如1.2.3-SNAPSHOT)的工件。这似乎是因为packages in Azure are immutable。
根据我的理解,这意味着Azure工件无法用于存储正在进行的快照工件。正确吗?
如果是,是否还有其他替代方法仍在使用Azure DevOps?我可以publish artifacts to Azure Blob Storage看到,但是大概这是您必须在现有的Azure Artifacts使用之上付出的代价。我还可以看到有很多GitHub Maven plugins可以将GitHub存储库视为Maven存储库,但是我找不到使用Azure DevOps存储库作为发布Maven工件的地方类似的东西。
以防万一,我在说的是基于云的Azure东西,不在本地。
答案 0 :(得分:0)
程序包管理的前提是程序包是不可变的。这将启用一大堆原本不存在的缓存选项。程序包存储在本地程序包缓存中,可能存储在代理供稿程序包缓存中,所有这些元素均假定具有相同名称和版本的程序包保持不变,并且将提供缓存的版本,而不是您推送的最新版本。大多数包装系统都是在此前提下构建的,包括Nuget和NPM。
创建开发快照的技巧是使用语义版本控制,并在您的版本中添加一个唯一的后缀。例如,1.2.3-SNAPSHOT.1
后跟1.2.3-SNAPSHOT.2
,有一些适用于Azure Pipelines的工具,例如GitVersion,它们可以自动生成唯一的版本+后缀,您可以将其传递到工件的版本中。 / p>
如果您不想“弄乱”您的主程序包提要,则可以出于开发目的设置另一个提要,其中包含所有中间包,然后您可以将其中一个程序包升级到您的主提要中,或者可以运行特定的管道(配置)以将最终软件包推送到用于稳定软件包的Feed中。
答案 1 :(得分:0)
看起来这主要是一个功能,而不是保留构建结果不变性的错误-意味着,无论该构建何时运行,它都将始终返回相同的结果。请参阅:How to update a maven dependency with a same version number in Azure Artifacts和Azure Artifact Publishing Fails for Artifact Version Containing '+'
答案 2 :(得分:0)
专门针对Maven,与其他版本相比,罐子在SNAPSHOT中的包装方式有所不同。
例如。假设我将jar的版本设置为1.0.0-PRERELEASE,现在此版本是不可变的。一旦将其发布到任何工件存储库,就不能覆盖它。通常,程序包管理系统将工件存储在这种逻辑路径-<group_id>/<artifact_id>/<version>/<artifact_id>_<version>.jar
中。
但是对于快照来说,这略有不同。在行家中,快照是可变的。这意味着您可以覆盖SNAPSHOT。这是有道理的,因为按照定义,SNAPSHOT就像是在积极开发中的代码映像。快照存储在包管理源中的方式类似于<group_id>/<artifact_id>/<version(SNAPSHOT)>/<artifact_id>_<version>_<jar_timestamp>.jar
。
在这种情况下,此jar的命名约定使其可变。在单个SNAPSHOT版本中,可能存在带有不同时间戳的多个jar。而且,当maven寻找SNAPSHOT依赖项进行下载时,它总是会选择最新的(出于逻辑考虑,因为这是最新的快照)。
目前,天蓝色文物正好按照预期的方式实现了这些概念。也许以前不存在,并且已经推送了更新。
http://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version https://xebia.com/blog/continuous-releasing-of-maven-artifacts/