18c58dc9c7
Bundler needs one source for internal and public gems, but gems virtuals have no merger, so a local gems repo and rubygems.org cannot be served together. - merge `info/<gem>` across members (member order wins a duplicate version-platform); pass a single-member gem through verbatim - regenerate `versions` lines and md5s for gems several members list; union `names` - 302 `gems/*.gem` and `quick/Marshal.4.8/*` to the member owning that version, via the shared member-path validation - return 502 on a member error; cache merges in the shared virtual cache; route HEAD on virtuals - add `docs/gems/virtual.md` and a stock `ruby:3.3` bundler e2e-docker case Reviewed-on: #154 Co-authored-by: unkin-agent <unkin-agent@unkin.net> Co-committed-by: unkin-agent <unkin-agent@unkin.net>
1.0 KiB
1.0 KiB
gems virtual
A gems virtual serves one RubyGems source over local and remote gems members:
gem install and bundle install work against /api/v1/virtual/<name>/.
info/<gem>is the union of member lines; on a duplicate version-platform the earlier member wins. A gem only one member has is served verbatim.versionsregenerates the line (and md5) of every gem several members list from its mergedinfo; other gems' lines pass through.namesis the union.gems/*.gemandquick/Marshal.4.8/*.gemspec.rz302 to the member whoseinfoline won.- A member error fails the request with 502; a member without the gem is skipped. Merges are cached for 60s.
resource "artifactapi_virtual" "gems" {
name = "gems"
package_type = "gems"
members = [artifactapi_local_gems.internal.name, artifactapi_remote_gems.rubygems.name]
}
# Gemfile
source "https://artifactapi.example.com/api/v1/virtual/gems/"
Push to the local member directly; the virtual is read-only.