Uploading Build Artifacts to Third‑Party Repositories (Nexus and GitLab)

This guide explains how to upload build artifacts to external repositories, first using Nexus as an example and then GitLab's built‑in generic package registry.

Upload to Nexus : A CI job named .pushartifact checks that the project type is Java, renames the generated JAR, and uses a curl POST request to the Nexus REST endpoint http://192.168.1.200:8081/service/rest/v1/components?repository=mylocalrepo with multipart/form‑data fields for the artifact and authentication admin:admin123 .

.pushartifact:
  tags:
    - build
  stage: pushartifact
  script: |
    if [[ ${PROJECT_TYPE} == "java" ]]; then
      pkgName=`ls target/ | grep -e "jar$"`
      cd target/
      mv ${pkgName} ${CI_PROJECT_NAME}-${CI_COMMIT_SHA}.jar
      curl -X POST "http://192.168.1.200:8081/service/rest/v1/components?repository=mylocalrepo" \
        -H "accept: application/json" \
        -H "Content-Type: multipart/form-data" \
        -F "raw.directory=/${CI_PROJECT_ROOT_NAMESPACE}/${CI_PROJECT_NAME}/${CI_COMMIT_SHA}/" \
        -F "raw.asset1=@${CI_PROJECT_NAME}-${CI_COMMIT_SHA}.jar;type=application/java-archive" \
        -F "raw.asset1.filename=${CI_PROJECT_NAME}-${CI_COMMIT_SHA}.jar" \
        -u admin:admin123
    else
      echo "PROJECT_TYPE ERROR [java]"
    fi

GitLab built‑in package registry : GitLab can serve as a private or public package repository for many package managers, allowing easy sharing of artifacts as dependencies for downstream projects.

Supported repository types are shown in the original images. For the generic package repository, three authentication methods are available: a personal access token, the CI job token ( ${CI_JOB_TOKEN} ), or a Deploy token created in project settings.

The upload endpoint format is:

PUT /projects/:id/packages/generic/:package_name/:package_version/:file_name?status=:status

Required parameters include project ID, package name, version, file name, and optional status (default/hidden).

Example upload command:

curl --header "PRIVATE-TOKEN: apF1R9s9JJBYJzLF5mYd" \
  --upload-file sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar \
  "http://192.168.1.200/api/v4/projects/33/packages/generic/devops03-maven-service/0.0.1/sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar?status=default"

Response example:

{
  "message": "201 Created"
}

When a package with the same name and version already exists, the new file is added as an additional version, and both UI and API can access historical files.

Downloading a package uses the GET endpoint:

GET /projects/:id/packages/generic/:package_name/:package_version/:file_name

Example download command:

curl --header "PRIVATE-TOKEN:
" \
  "http://192.168.1.200/api/v4/projects/33/packages/generic/devops03-maven-service/0.0.1/sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar"

GitLab CI/CD example : The .pushartforgitlab job mirrors the Nexus example but uses the CI job token and the generic package upload URL, handling the same Java‑project check and artifact renaming before publishing.

.pushartforgitlab:
  tags:
    - build
  stage: pushartifact
  script: |
    if [[ ${PROJECT_TYPE} == "java" ]]; then
      newPkgName=${CI_PROJECT_NAME}-${CI_COMMIT_SHA}.jar
      pkgName=`ls target/ | grep -e "jar$"`
      cd target/
      mv ${pkgName} ${newPkgName}
      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" \
        --upload-file ${newPkgName} \
        "http://192.168.1.200/api/v4/projects/${CI_PROJECT_ID}/packages/generic/${CI_PROJECT_NAME}/${CI_COMMIT_SHA}/${newPkgName}?status=default"
    else
      echo "PROJECT_TYPE ERROR [java]"
    fi