JFrog Platform Guide

Appearance

Migration to Supplier Instance ​

Migrating a Supplier to the Supplier instance is a straight-forward process. Once you've identified the repositories and users who need to utilize the Supplier instance, a couple of ServiceNow tickets will get everything taken care of.

Pre-migration requirements ​

Before embarking on your JFrog migration, it's crucial to understand the fundamental distinctions between local and remote repositories, so you can identify how you are interacting the the platform and how you plan you storage in the new environment.

Local repositories are those hosted directly within your JFrog Artifactory instance, designed to store and manage artifacts that are produced internally by your organization. Remote repositories act as caching proxies for external artifact sources, such as Maven Central, npmjs.com, Docker Hub, or other public or private third-party registries.

Considerations for Migration ​

Before proceeding with the migration details, please review the following criteria to determine if migration is necessary for your user type:

  • Employee Type "M" using Corporate Devices (VPN or VDI): If you are an employee of type "M" and connect to the JFrog platform using a VPN on a corporate device or through a VDI (Virtual Desktop Infrastructure), you must not migrate to the new platform. This migration's security constraints are specifically focused on suppliers using non-corporate devices or internal connections. Your current setup already meets the necessary security requirements, and no action is needed from your side.
  • Employee Types "M" or "S" without VPN or VDI: If you are an employee of type "M" or "S" and you currently access jfrog.ford.com without using either a VPN or VDI, you are required to migrate to the new platform. Please follow the detailed migration steps below based on your specific needs.

Migration Steps ​

Identify Repositories and Users ​

First thing, you must identify which users/groups are utilizing data in your project. You may already have an understanding of which suppliers you are working with. For ease of management, it is best to have the suppliers you are working with in their own security group(s).

Next, you will want to understand which repositories your suppliers are working in. Make a list of repositories that you collaborate with suppliers on.

Onboard to Supplier Instance ​

Once you have identified the user groups representing your suppliers, you can create a Service Now ticket (Submitting a ServiceNow ticket). You will need to request a new project on the Supplier instance. Additional instructions for this process is available Project Creation Process. The project on the Supplier instance does not have to be the same as what is on the Primary instance.

In addition to project creation, include which supplier groups need to be onboarded to the Supplier instance.

Once this is done, you can login to the Supplier instance (https://supplier.artifacts.ford.com), and begin setting up any repositories that you may need. This includes creating federation partners to any repository on the Primary instance that will need to be synced to the Supplier instance.

Create a New Access Token and Update ARTIFACTORY_PASSWORD ​

Once you have gained access to the new supplier server, you will need to generate a new access token. This token is essential for authentication and authorization on the new platform. JFrog documentation highlights that access tokens are a flexible means of authentication, offering enhanced security over traditional username/password combinations. After generating the token, you must update the ARTIFACTORY_PASSWORD environment variable in your local development environment with this new token. This ensures that your local tools and scripts can securely connect to and interact with the new JFrog server.

Update the JFrog URL ​

You must update the JFrog URL in all your configurations. Change all instances of https://jfrog.ford.com to https://supplier.artifacts.ford.com. It is critical to note that the rest of the URL path following the base domain should not be modified. For example, if your current URL is https://jfrog.ford.com/artifactory/external-proxy-group/, it should be updated to https://supplier.artifacts.ford.com/artifactory/external-proxy-group/. Changing the base URL can have significant impacts, especially for federated repositories, but the specific instruction here is to retain the path structure.

If your use case primarily involves consuming artifacts solely from remote repositories, you will not be required to create a dedicated project. This is because, by default, remote repositories are configured to be visible and accessible to all users and groups within the JPD

Federate Repositories ​

If your workflow requires access to specific local repositories for consuming or pushing binaries, you can request that your repositories are federated. Federation allows multiple repositories (even across instances of JFrog), can be kept in sync with the ability to read and write on all repositories within the federation group. We can also use federation as a migration tool, so even if you're only migrating the data, and you don't want them to be in sync in the future, include those repositories and stipulations in your submitted ticket. For more details, see the page Federate Repositories in the JFrog Platform.

GitLFS Migration ​

Due to new security requirements, specifically the implementation of IP filtering on JFrog Artifactory, access to binaries and LFS content stored within JFrog will be restricted for external suppliers. To maintain seamless access for our supplier partners and comply with the Cyber Security constrains, all Git LFS files associated with artifactory LFS repositories must be migrated from JFrog Artifactory to GitHub.com. This ensures that suppliers can consume LFS files directly from GitHub Cloud, bypassing the IP filtering restrictions on JFrog.

Prerequisites for Migration

Before initiating the LFS migration, please ensure the following conditions are met for your repository:

  • GitHub Repository Migration: Your GitHub repository, which utilizes LFS, must already be migrated to GitHub.com (GitHub SaaS). This migration specifically addresses LFS files for repositories already hosted on GitHub.com.

Migration Process Steps

Once the prerequisites are satisfied, follow these steps to facilitate the LFS migration:

  • Initiate Migration Request via ServiceNow: Submit a service request through the designated ServiceNow queue: https://github-guide.ford.com/ch07/01-sno-support.html#ford-support-request-process-servicenow. In your request, clearly state that you are requesting an LFS migration to GitHub.com. You will need to provide the following essential information:

    • The name of the Artifactory repository currently hosting the LFS files.
    • The destination GitHub.com repository (<ORG_NAME>/<REPO_NAME>) where the LFS files should be migrated.

  • GitHub Team Performs Migration: Upon receiving your request, the GitHub team will perform the necessary migration steps. This process involves transferring the LFS objects from your specified Artifactory repository to the target GitHub.com repository. As part of this migration, the LFS endpoint configuration within your GitHub repository will be updated to point to the new GitHub LFS storage. The LFS endpoint in your Git configuration (.git/config) will be modified to reflect the following format:

[lfs]
url = https://github.com/<ORG_NAME>/<REPO_NAME>/info/lfs  ##This change ensures that your Git clients will fetch LFS files directly from GitHub.com.
  • Pre-Migration Alignment: Before executing the migration, the GitHub team will reach out to you directly. This contact is to ensure alignment on the migration schedule and any specific considerations, preventing disruption and confirming all parties are prepared for the change.

Brought to you by DevTools and Enablement Team.

Copyright © 2019-present Ford Motor Company