通过刷新本地依赖测试Artifactory访问的各构建工具命令及Python实现

排查Artifactory间歇性服务中断时，本地已缓存的依赖会掩盖真实的连通性、可用性问题，核心验证逻辑是强制绕过本地依赖缓存，触发所有依赖对Artifactory的访问请求，以此复现故障、验证服务状态。Gradle场景下使用的基准命令为./gradlew build --refresh-dependencies，该命令会忽略本地缓存的过期标记，对所有声明的依赖、插件发起远程校验，存在版本变动或哈希不匹配时重新拉取，再完成完整构建流程。

不同JVM构建工具的命令等效性判断 #

• Maven命令mvn clean install -U：默认场景下部分等效，调整后可完全对齐
  参数-U会强制检查所有快照版本依赖的远程更新，同时会重新拉取本地缓存损坏、元数据缺失的正式发布版依赖，但对本地缓存完整的正式版依赖不会主动发起远程校验。如果需要完全对齐Gradle基准命令的验证效果，最简便的方式是执行命令时指定一个空的本地仓库目录，彻底排除本地缓存干扰：
  mvn clean install -U -Dmaven.repo.local=/tmp/empty-maven-repo
  执行时所有依赖都会从Artifactory拉取，完全满足验证要求。
• SBT命令序列sbt update、sbt clean、sbt compile：默认配置下不等效
  SBT默认的update逻辑仅会主动检查快照版本依赖的更新，对本地缓存完整的正式版依赖不会发起任何远程请求，无法触发全量Artifactory访问，很容易漏过间歇性故障。要实现等效效果，可以在执行命令时指定空的ivy/sbt缓存目录，强制全量拉取：
  sbt -Dsbt.ivy.home=/tmp/empty-ivy -Dsbt.boot.directory=/tmp/empty-sbt-boot clean compile
  执行过程中所有依赖都会从配置的Artifactory地址拉取，达到验证目的。

Python生态的等效验证操作 #

Python属于解释型语言，依赖拉取逻辑和JVM构建工具有差异，核心验证思路同样是绕过本地全局缓存、当前环境已安装依赖，强制从Artifactory PyPI源拉取全量依赖，不同包管理工具对应操作如下：

• pip（默认通用包管理工具）
  最稳妥的方式是创建一个全新的空虚拟环境，在环境内执行无缓存安装命令，完全不碰本地已有缓存：

  # 创建临时空虚拟环境
  python -m venv /tmp/test-venv
  # 激活虚拟环境，Windows系统执行 /tmp/test-venv/Scripts/activate
  source /tmp/test-venv/bin/activate
  # 强制无缓存从Artifactory源拉取所有依赖
  pip install --no-cache-dir -r requirements.txt
  # 可选：执行测试/启动命令验证依赖可用
  pytest
  

  必须加--no-cache-dir参数，否则pip会优先读取本地全局缓存的包文件，不会发起对Artifactory的请求。
• Poetry
  执行命令清空对应源的缓存后，使用无缓存参数安装即可：

  # 清除配置的Artifactory源本地缓存，<artifactory-source-name>替换为Poetry配置中对应的源名称
  poetry cache clear --all <artifactory-source-name>
  # 无缓存安装全量依赖
  poetry install --no-cache
  

• PDM
  对应操作更简单，直接执行带无缓存参数的安装命令即可：
  pdm install --no-cache

所有工具的验证逻辑核心一致：必须保证执行过程中会对项目用到的所有依赖发起对Artifactory的访问请求，不能只做构建产物清理，否则无法触发服务端交互，达不到排查间歇性故障的目的。

内容的提问来源于stack exchange，提问作者Hofbr