|
* Packagecloud<ref>{{cite web|url=https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0 |title=Publishing npm Packages Using CircleCI 2.0 - CircleCI | last=canals | first=armando |date= 31 March 2018 | website=circleci.com}}</ref>
* Sonatype Nexus
== Relationship to continuous integration ==
As part of the development lifecycle, source code is continuously being built into binary artifacts using [[continuous integration]]. This may interact with a binary repository manager much like a developer would by getting artifacts from the repositories and pushing builds there. Tight integration with CI servers enables the storage of important metadata such as:
* Which user triggered the build (whether manually or by committing to revision control)
* Which modules were built
* Which sources were used (commit id, revision, branch)
* Dependencies used
* Environment variables
* Packages installed
=== Artifacts and packages ===
Artifacts and packages inherently mean different things. Artifacts are simply an output or collection of files (ex. JAR, WAR, DLLS, RPM etc.) and one of those files may contain metadata (e.g. POM file). Whereas packages are a single archive file in a well-defined format (ex. [[NuGet]]) that contain files appropriate for the package type (ex. DLL, PDB).<ref name="sharedlibrary">{{Cite journal| last = Chris | first = Tucker | title = Optimal Package Install/Uninstall Manager | publisher = UC San Diego | date = 2007-03-15| page=1 | url = http://cseweb.ucsd.edu/~lerner/papers/opium.pdf | accessdate = 2011-09-14}}</ref> Many artifacts result from builds but other types are crucial as well. Packages are essentially one of two things: a library or an application.<ref>{{Cite web| title=Linux repository classification schemes | url=http://braintickle.blogspot.com/2006/01/linux-repository-classification.html|publisher=braintickle.blogspot.com | accessdate=2008-03-01}}</ref>
Compared to source files, binary artifacts are often larger by orders of magnitude, they are rarely deleted or overwritten (except for rare cases such as snapshots or nightly builds), and they are usually accompanied by lots of metadata such as id, package name, version, license and more.
=== Metadata ===
[[Metadata]] describes a binary artifact, is stored and specified separately from the artifact itself, and can have several additional uses. The following table shows some common metadata types and their uses:
{| class="wikitable"
|-
! Metadata type !! Used for
|-
| Versions available || Upgrading and downgrading automatically
|-
| Dependencies || Specify other artifacts that the current artifact depends on
|-
| Downstream dependencies || Specify other artifacts that depend on the current artifact
|-
| License || Legal compliance
|-
| Build date and time || Traceability
|-
| Documentation || Provide offline availability for contextual documentation in IDEs
|-
| Approval information || Traceability
|-
| Metrics || Code coverage, compliance to rules, test results
|-
| User-created metadata || Custom reports and processes
|}
==References==
| 