CONTROLLED DATA
Leidos Proprietary - US Citizens ONLY
The information contained herein is proprietary to Leidos, Inc. It may not be used, reproduced, disclosed, or exported without the written approval of Leidos.

  • Created by Unknown User (johnsonli), last modified on Dec 13, 2019

This article describes SecDevOps use of Artifactory and project repositories.

Repositories and Permissions

For every project in SecDevOps who requests the Bamboo Pipeline or Artifactory will have the following provisioned when the request is made.

  • Repositories - Two repositories will be created for the project as follows:
    • Snapshot - stores the local snapshots of the product
      • The naming convention is <project key>-<name>-dev-local
      • Example for the Save The Planet project with STP as the project key: stp-maven-dev-local
    • Release version - stores the release versions of the product
      • The naming convention is <project key>-<optional>-release-local
      • Example for the Save The Planet project with STP as the project key:  stp-maven-release-local
  • Permissions - Every project is created with two groups, admins and users.  As follows, there are two permission targets for the project's Artifactory repositories
    • Admins
      • The naming convention is sdo.project-<project key>.admins
      • Example for the Make My Day project with MMD as the project key: sdo.project-mmd.admins
      • The permission target for admins allows Read, Annotate, Deploy/Cache, Delete/Overwrite, and Manage privileges in repositories in Artifactory
      • Has read/write access to the MMD local maven ‘dev’ and ‘release’ repositories.
    • Users
      • The naming convention is sdo.project-<project-key>.users
      • Example for the Make My Day project with MMD as the project key: sdo.project-mmd.users
      • The permission target for admins allows Read, Annotate, Deploy/Cache, Delete/Overwrite privileges in repositories in Artifactory 


Since SecDevOps is a multi-tenant secure environment, firewall rules block direct access to public sites. To remediate this, the SecDevOps architecture utilizes a unique mechanism that provides secure build and deployment access to remote public repositories; a DMZ with a separate instance of Artifactory and wider access to the internet. The packages that are uploaded into the DMZ repositories are scanned for vulnerabilities before they can be used. Once the project has added the required packages to the DMZ, they can configure their project repositories in SecDevOps such that it pulls packages from the DMZ Artifactory.

<insert diagram that supports the Project Artifactory repos and DMZ Artifactory repo pull>


Quirks and Troubleshooting

Quirk:  Default write to snapshot directory

One quirk of Artifactory is to have a ‘default writable’ repository when the SecDevOps Engineers set up your virtual repository. If you are using the virtual repository name in your maven settings.xml file it will, by default, try to write to the snapshot repository (if your artifacts are tagged with releases and not SNAPSHOTs, you will get an error if you use the virtual repository name).

Quirk:  Default User

Make sure your settings.xml file reflects the proper user. If you are running builds in Bamboo, your settings.xml file should be specifying the identity of your service account (SRVC-<project-key>). That way CI builds are attributed to the service account and not a project person. There are different password retention times for service accounts, they don’t expire as quickly as user account.

Failed to execute goal on project: Could not resolve dependencies for project...

The following error indicates the remote repository is missing.  The SecDevOps environment does not have direct access to many of the publicly available repositories.

build   26-Apr-2019 12:35:21   [ERROR] Failed to execute goal on project StpServices: Could not resolve dependencies for project com.leidos:StpServices:war:02-2019.0003: Failed to collect dependencies at com.oracle.weblogic:wls-api:jar:12.1.3-0-0: Failed to read artifact descriptor for com.oracle.weblogic:wls-api:jar:12.1.3-0-0: Could not transfer artifact com.oracle.weblogic:wls-api:pom:12.1.3-0-0 from/to maven.oracle.com (https://maven.oracle.com): Connection reset -> [Help 1]

build   26-Apr-2019 12:35:21   org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project StpServices: Could not resolve dependencies for project com.leidos:StpServices:war:02-2019.0003: Failed to collect dependencies at com.oracle.weblogic:wls-api:jar:12.1.3-0-0

The error above means we haven’t set up a remote repository to maven.oracle.com yet. This is the case where the remote repository needs to be placed in the DMZ Artifactory and the project needs to configure their repositories to pull from the DMZ Artifactory (rather than public sites).

Cannot deploy file ...

The following error indicates an attempt to store a release version in the snapshot repository.

Cannot deploy file 'wls-api-12.1.3-0-0.jar'. The repository 'mpacs-maven-dev-local' rejected the resolution of an artifact 'mpacs-maven-dev-local:com/oracle/weblogic/wls-api/12.1.3-0-0/wls-api-12.1.3-0-0.jar' due to conflict in the snapshot release handling policy.

This error is corrected by deploying to 'mpacs-maven-release-local' rather than 'dev-local'.


You may also want to use visual panels to communicate related information, tips or things users need to be aware of.




The information contained herein is proprietary to Leidos, Inc. It may not be used, reproduced, disclosed, or exported without the written approval of Leidos.
CONTROLLED DATA