Composer结合JFrog Artifactory构建企业级制品库的集成方案-composer-PHP中文网

composer配置artifactory私有仓库需在composer.json的repositories中声明type为"composer"、url严格匹配artifactory repository key（如https://artifactory.example.com/artifactory/api/composer/php-composer/），末尾斜杠不可省略；同时须在auth.json中配置对应域名的http基础认证，且仓库类型必须为composer而非generic或remote。

composer结合jfrog artifactory构建企业级制品库的集成方案

Composer如何配置私有仓库指向Artifactory的Composer Repository

Composer默认只认packagist.org，要让它拉取Artifactory托管的PHP包，必须显式声明私有仓库。关键不是加个URL就行，而是得匹配Artifactory上实际启用的Repository Key（比如php-composer），且协议必须是https（除非内网明确允许http）。

在项目根目录的composer.json里，用repositories字段声明：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://artifactory.example.com/artifactory/api/composer/php-composer/"
    }
  ]
}

注意末尾斜杠不能少——Artifactory的Composer API要求路径严格匹配，漏掉会返回404 Not Found或Invalid repository type。

如果Artifactory启用了权限控制，必须提前在auth.json中配置凭据，否则composer install会卡在认证环节
不要把私有仓库设为"packagist": false，除非你真不需要任何公开包；更稳妥的做法是把私有源放在列表首位，让Composer优先查找
Artifactory的Repository Type必须是Composer，不是Generic或Remote——类型选错会导致元数据生成失败，composer search查不到包

如何让Artifactory正确代理Packagist并缓存第三方包

直接把packagist.org加进Artifactory的Remote Repository，不等于就能无缝代理。Artifactory对Composer协议的支持依赖于反向代理头和路径重写规则，缺一不可。

创建Remote Repository时，关键配置项：

URL填https://packagist.org，别带/packages.json之类后缀
勾选Handle Binaries（否则.zip包下载失败）
在Advanced Settings里开启Store Artifacts Locally，否则只是直连转发，起不到缓存作用
务必设置Offline Mode为false，否则网络波动时会直接报错而非回退本地缓存

验证是否生效：执行composer show monolog/monolog，看输出里的source路径是否指向你的Artifactory域名。如果还是packagist.org，说明Composer没走代理——大概率是repositories顺序不对，或本地composer config -g repos.packagist.org被手动禁用了。

发布私有包到Artifactory时为什么`composer publish`报错

Composer本身没有composer publish命令。这是常见误解：发布PHP包到Artifactory，靠的是curl或artifactory-cli上传.tar包，再触发元数据重建，不是用Composer客户端推。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

标准流程分三步：

打包：composer archive --format=zip --file=vendor-name/package-name-1.2.3.zip
上传：curl -u user:api-key -X PUT "https://artifactory.example.com/artifactory/php-composer/vendor-name/package-name/1.2.3/package-name-1.2.3.zip" --data-binary "@vendor-name/package-name-1.2.3.zip"
刷新索引：curl -u user:api-key -X POST "https://artifactory.example.com/artifactory/api/composer/php-composer/v1/reindex"

容易踩的坑：

上传路径里的版本号必须和composer.json里version字段完全一致，包括v1.2.3和1.2.3的区别
Artifactory的php-composer仓库需开启Index Sources，否则composer require时找不到包
API Key权限必须包含Deploy/Cache和Manage，仅Read权限会导致403 Forbidden

CI流水线中如何安全注入Artifactory凭据而不硬编码

在GitHub Actions或Jenkins里写死用户名密码，等于把仓库钥匙贴在代码库里。正确做法是利用CI平台的Secret机制，配合Composer的auth.json动态生成。

以GitHub Actions为例，在steps中插入：

- name: Setup auth.json
  run: |
    mkdir -p $HOME/.composer
    cat > $HOME/.composer/auth.json <p>注意两点：</p>

auth.json里的域名必须和composer.json中仓库URL的host完全一致（比如artifactory.example.com不能写成https://artifactory.example.com）
Artifactory的API Key不能用Web UI密码替代——必须在User Profile → API Key → Generate API Key里单独生成
如果CI环境同时访问多个Artifactory实例，auth.json里可以定义多个http-basic条目，Composer会自动匹配对应域名

真正麻烦的不是配置本身，而是权限收敛：每个项目组应该只拥有自己命名空间下的Deploy权限，而不是整个php-composer仓库的管理员权限。这点在Artifactory的Permission Target里容易漏配，导致CI跑通但开发机拉不到包。