Making workspace releases

Helix IPLM captures the design state at the IP level in releases. IP releases are also referred to as IP Versions (IPVs). An IP release is a specific version of an IP, that contains design files, resources and project properties. Resources are other IPs included in this IP at specific versions while project properties consist of properties like path and local/refer modes.

Workspace releases

Workspace releases are captured from a workspace that has been modified versus an existing release. See the IP Versions (Releases) section for more information on Helix IPLM Releases. File contents of IPVs are commonly modified, and resources moved to different versions that that specified by the top level IPV loaded into the workspace (via the pi up command, detailed in the Updating the Workspace section). If modifications have been made and checked into the DM system, and/or resources have been changed, a new release can be captured and published back to the Helix IPLM server.

A typical example is shown in the below diagram. A Helix IPLM release IP@52 is loaded or updated into the workspace, changes are made at the DM (p4 sync/submit) and at the Helix IPLM IP level (pi up) resulting in a modified workspace as shown by the workspace status. Once modified, a new release IP@53 can be created and published back to the Helix IPLM server. Perforce is shown as the DM system in this case, but the flow is the same for any DM type.

Workspace permissions impact

Helix IPLM supports 'Partial Workspaces' in which workspaces can be built from an IP Hierarchy for which a user doesn't have permissions to all the IPs in the hierarchy. Workspace releases will work normally for a user in a Partial Workspace, with the IPVs that the user doesn't have read permission to being kept at their existing release for new releases.

See the Workspaces and Permissions section for additional information.

Releases of IPs @HEAD

IPs @HEAD can be used as the basis to create a new fixed release IPV. To make a release, either a resource modification versus the @LATEST version of the IP must have been made, or one or more files in the IP must have been updated beyond the version captured in the @LATEST release.

A new fixed release (the new @LATEST) IPV on the line is created, but the IPV in the workspace is left @HEAD. 

Hierarchical releases

The IP Hierarchy is built up one layer at a time, with each IPV pointing to a set of IP resources (or children). These resources may have resources of their own, and those resources may also have resources, and so on. In this way a full IP Hierarchy, also called a Component and IP BOM (CIPB), is constructed. 

In a workspace changes may have been made at various levels of the workspace hierarchy, necessitating making releases of each IPV in the hierarchy that has modified resources. In a large hierarchy this can take some time, to automate the process Helix IPLM provides a hierarchical release option that will perform a hierarchical update algorithm that will go up the tree from bottom to top and make the necessary releases up to the top level IPV in the workspace. See --hier option in the 'pi release' command options below.

Releasing refer mode IPs

Refer mode IPVs are located in the read-only areas managed by IPLM Cache and, if they are at a fixed release, will not have any file modifications. If refer mode IPVs have resource modifications new releases can be created for those IPVs.

Refer mode IPVs loaded in the cache @HEAD can also be used to create new releases, on the basis of file changes, if any file win the IPV has been updated to a newer version that those captured in the LATEST release.

Unmanaged files

Unmanaged files are ignored by Helix IPLM when making a new release.

Releasing resource IPs

The 'pi release' command accepts an 'ip' option, this can be used to release a specific resource IP, even if it isn't the top level IPV in the workspace. 

Command line

Releases are created from the workspace with the 'pi release' command.

pi release Command 
> pi release -h
Usage: pi release [-h] [--args ARGS] [--description DESCRIPTION]
                  [--hier | --allow-from-old | --from-filelist FILE | --revision REVISION]
                  [--ignore-open]
                  [ip]

Description: Make a new release. If no IP Line is specified and the release
command is run from within a Workspace, only the top level IP in the Workspace
will be released. None of the resources of the specified IP will be released.
May only run from outside of any Workspace with the '--from-filelist' or '--
revision' options, in which case the IP Line identifier must be specified.

Positional arguments:
  ip                    The IP Line identifier. If the release command is run
                        from within a Workspace, the default is the Line of
                        the top IP of the Workspace. With a partial identifier
                        of the form 'LIB.IP' without a Line, the identifier
                        expands to whichever Line of the IP is present in the
                        Workspace. When '--from-filelist' or '--revision' is
                        used, the fully expanded IP Line identifier must be
                        provided.

Optional arguments:
  --allow-from-old      Allow release even if the IPV in the Workspace is not
                        the latest release (not allowed with '--hier').
  --allow-modified      Allow release when workspace has 'added' or 'removed'
                        resources.
  --args ARGS           Arguments passed to the hooks.
  --description DESCRIPTION, -m DESCRIPTION, -d DESCRIPTION
                        Short description of the release.
  --from-filelist FILE  Release with a user-supplied filelist. This option
                        cannot be used with the '--allow-from-old', '--hier'
                        or '--revision' and an IP Line identifier must be
                        specified.
  --hier                Perform a hierarchical release of the entire
                        Workspace. If an IP Line identifier is passed to the
                        command, it will be ignored.
  --ignore-open, -i     Ignore open files (local changes).
  --revision REVISION   Create a revision release with user-supplied revision
                        or changelist number. Cannot be used with the options
                        '--allow-from-old', '--hier' or '--from-filelist' and
                        an IP Line identifier must be specified.
  -h, --help            Show this help message and exit

Release behavior modifiers

The restrictions on making releases can be modified with these options.

Command Option Description
--allow-from-old Normally an IPV in the workspace must be at the latest version before it can be release. This is to ensure that other users modifications are incorporated into any new release. This option bypasses that requirement and releases from older IPVs.
--ignore-open, -i Files that are modified but not checked in to the DM system will normally block a release. This restriction is to ensure the contents of the workspace are accurately captured. This option will cause the checked in version of the file that is being modified to be included in the release, and to ignore any open files.
--allow-modified When an IPV in a workspace has resources that have been added or removed via the pi workspace edit command, pi release will by default prevent a release of that IPV, unless the --allow-modified flag is supplied. This is to prevent unintentional release of IPVs with resources modified by 'pi workspace edit'.

Special release mechanisms

Server side releases normally don't modify the file list, they modify the resources and metadata associated with the IP. SeeIP Versions (Releases) for more information. These options allow releasing IPVs with file contents that are specified directly, bypassing any workspace. These options are useful for creating a release from DM level data that is already checked in, as when migrating from a legacy system into Helix IPLM. Detailed information can be found on the Special Release Mechanisms page. 

Command Option Description
--from-fileliist FILE Release using a user supplied filelist. Supported for Perforce type IPs
--revision REVISION Release using a user supplied revision. Supported for Perforce (changelist), Subversion (repo version), and DM Handlers (if the capability is implemented in the DM integration)

Additional options

Command Option Description
--args ARGS Arguments passed in to client side hooks or to the DM Handler (if the IP is a DM Handler). Format is: --args="-arg1 value1 -arg2 value2 -arg3"
--description A description of the release
--hier Perform a hierarchical release. This will release IPVs from the lowest hierarchy levels up to the top to capture all modifications in the workspace

Example release

The following example shows making a DM level modification and the creating a Helix IPLM release.

> p4 submit -d "changes to test"Submitting change 337.
Locking 1 files ...
edit //depot/coco/CPU/rtl/test.v#2
Change 337 submitted.
 
 
> pi release -d "New release with test changes"Successfully created coco.CPU@25.TRUNK.

Viewing the new release

The new release can be viewed via the IP Catalog, see the Listing IPs in the Catalog section for details.

Release restrictions

  • No Open & Modified Files In Workspace: Helix IPLM only works on checked in files - it is necessary to make sure that all changes are checked into version control. By virtue of checking your changes in, users have to resolve any version control conflicts that may arise. If there are any open & modified files in your workspace, PI will issue a warning and abort the release for that IP. This restriction can be bypassed using the '--ignore-open' option (see above). In the case of P4 type IPs, open but unmodified files will be reverted.
  • No Added or removed IPV resources: By default IPLM will prevent release of IPVs in a workspace which have added or removed resources (via the pi workspace edit command), the '--allow-modified' option (see above) can be used to override this restriction. See Editing Workspace Resources for more details.
  • No Backwards Releases: IP releases cannot go backwards - at the time of release, if the same IP has been released from a different workspace, then the release will be aborted. The user had to sync the workspace to the latest release first and then attempt the release again. This restriction can be bypassed with the 'pi release --allow-from-old' option.
  • No Duplicate Releases: At the time of release, PI will check to make sure that at least one item on the filelist or resource list is different from the latest release of this IP (not just from the release that the workspace is currently on)
  • No Manually Modified p4 clients: Prior to release (for P4 type IPs) the p4 client view specification is checked against what is expected from the Helix IPLM IP CIPB. If modifications are found the release will be prevented. The p4 client can be corrected with the 'pi ws refresh --reset' command.