Miscellaneous

Origen Remotes

In some cases, your application may require access to external data that is kept under revision control but not necessarily as part of the Origen environment. For example, you may need access to a design file that is stored with the IP and rather than store a static copy in the application vault, you want to easy populate a local version based on a specified tag. Then what you need is an Origen Remote.

Populating a remote is extremely easy, all that has to be done is to define the required remote within the config/application.rb file.

Three of these four details are required (tag and version are mutually exclusive):

• dir: The sub-directory within the Origen remotes workspace where you want the population to occur, (aka. local)
• vault or rc_url: The path to the vault/repo, ‘vault’ and ‘rc_url’ can be used interchangeably
• version: The version that you want to use
• tag: The tag that you want to use

The difference between tag and version is that a version, if semantic, will get a ‘v’ prepended to it. This is due to a DesignSync requirement. A tag will get used as-is. In the examples below the first remote will ask DesignSync for version ‘v1.0.1’, whereas the second remote will ask Perforce for the tag ‘0.1.0’.

Once in possession of these details add them to the config.remotes attribute. This accepts an array and any number of remotes can be added, here is an example that populates three remotes:

config.remotes = [
  {
    dir: "source/include/v_ip_ate",
    vault: "sync://sync-15000:15000/v_ip_ate/compiler/include",
    version: "1.0.1",
  },
  {
    dir: "mydir",
    vault: "p4://myserver:myport//path/to/my/remote/file/myfile.xlsx",
    tag: '0.1.0'
  },
  {
    dir: "artwork",
    rc_url: "git@github.com:Origen-SDK/artwork.git",
    version: "master",
    development: true
  },
  {
    dir: "third_party_remote",
    rc_url: "https://github.com/third-party/remote.git",
    version: "1.2.3",
    disable_tag_prefix: true # repo is tagged as 1.2.3, not v1.2.3
  }  
]

Origen will populate all remotes defined by a top-level application. It will also populate all remotes defined by an application’s plugins, except for those which have been marked with development: true as in the 2nd example above.

Setting development: true, indicates to Origen that the remote is only required when developing the plugin within a standalone workspace, and that it is not required when the plugin is being used by a top-level application.

Origen follows the philosophy that version control tags should prepend a ‘v’ to the semantic version to communicate that the following numbers are a semantic version, e.g. 1.2.3 has a git tag of v1.2.3 (see SemVer documenation). However, sometimes you do not have control over the tagging conventions another repo is using and need to opt out of the tag prefixing. Set disable_tag_prefix: true for each remote that needs to query a tag without the leading ‘v’.

Population of the remotes will occur within the remotes workspace located at the top-level of the receiving application. For instance, in the above example, the v_ip_ate remote would be located at:

.<top>_remotes_DO_NOT_HAND_MODIFY/source/include/v_ip_ate

Please note that the value of dir must be unique for each remote within the application.

You can get a handle on the top-level remotes dir via the helper Origen.app.remotes_dir, as shown in this example:

data = File.read("#{Origen.app.remotes_dir}/source/include/v_ip_ate")

With those details added Origen will then take care of ensuring that the dependencies are fulfilled every time that the application is invoked.

If you are still developing some parts of your remote, your environment setup may need to be slightly different vs. working on a known good remote. You can configure the receiving application to use a development workspace like this:

config.remotes = [
  {
    dir: "source/include/v_ip_ate",
    vault: "sync://sync-15000:15000/v_ip_ate_c90lp/compiler/include",
    version: "v0.0.0.dev2",
    path: "/proj/thao/build.22/common_vip/v_ip_ate",
  }
]

When a path reference is present Origen will override the vault/version reference and will setup up a symbolic link from the regular remote location to your development workspace - this means that the receiving application is now always looking at your latest development code.

Origen will not allow the receiving application to be tagged when a path reference is active, so you don’t need to worry too much about forgetting to remove it!

Some applications need to support multiple products using source files from other repositories, and cannot put product specific information in the config/application.rb file. In this case, the remotes can be defined in the DUT initialization or a related callback method. Once defined, the remotes can then be fetched by executing the Origen.remote_manager.resolve_remotes! method.