Configure Nexus 3' staging repositories (BUILD-699)

[BUILD-1129] Create permanent staging repositories for public, enterprise, etc. Created: 11/Aug/23  Updated: 11/Aug/23  Resolved: 11/Aug/23

Status: Completed
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Mikaël Geljić
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Team: Foundation

 Description   

Nexus 3 staging no longer works with creating staging repos on the fly, but based on tagging & permanent staging repos.

Promotion happens by moving artifacts with a certain tag to a target destination repository.

Possible approaches

In theory, one shared staging repo would be sufficient, if we (or automation) keep track of which tag goes where. However, if promotion is a deferred step, and one inspects the content of that unique repo, it might be messy to identify e.g. if all community artifacts have been promoted, or which hanging artifacts need to be promoted where. 

Therefore, in order to be able to promote public, enterprise and other artifacts to their correct destination repos, it's gonna be more "magnolia-conventional" to have:

  • magnolia.public.snapshots
  • magnolia.public.staging (new)
  • magnolia.public.releases

Same for following repos/”scopes”:

  • magnolia.enterprise.*
  • magnolia.addons.*
  • magnolia.public.maintenance.*

Repos not using staging at this point:

  • magnolia.internal.*
  • magnolia.incubator.*
  • no need expressed so far.
  • staging is also usually skipped for parent POMs
    • (deploying to multiple repos within same reactor)

Validation points 🧪

  • cross visibility of artifacts from staging repo to other
    • (enterprise staged releases needing staged community artifacts)
  • config nxrm3 plugin with ${distribRepoPrefix}.staging in repository param

—via Nexus aftermath and Foundation impact @August 8, 2023


Generated at Sun Feb 11 23:48:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.