This method is causing some problems when some properties (isInstallable, isUniqueInstall, xmlInjection) doesn't exist in the cmfpackage.json file.

We need to refactor this logic and maybe remove that method.

A good test for this issue is run cmf pack in Test Package without that properties.

IoT bump should be consistent between all packages that are under the same root

All the file and directory searching is using the SearchPattern from DIrectoryInfo.
This Pattern doesn't support glob strings and usually returns more files/directories than needed.

cli needs a few enhancements to be fully compatible with DevOps Center (DOC) deployments

1. init should be able to accept DOC environment parameters instead of a Deployment Framework (DF) export as a configuration source (solved by #41)
2. must specify target layers for deployment packages, when necessary
   • these will be ignored by DF
3. the Release template must support DOC deployments
   • ideally we should ship 2 releases, a DF one and a DOC one, so that projects can test both scenarios
4. init should accept a base path used for all the package repository shares in GlobalVariables
   • this would remove the dependency on the vmHostname variable in the template, as this now refers only to the environment address (we could rename this variable accordingly)

• Environment: Microsoft Azure Cloud Agents: ubuntu-latest

• Issue:
  cli is installing at /home/vsts/work/[node_modules/.bin/cmf-cli/cmf] when it should be installed at /home/vsts/work/_temp/[node_modules/.bin/cmf-cli/cmf]. The temp path is expected when running the build and pack commands, which is causing pipelines to fail.

• Logs:
  Debug info did not provide anything useful and a manual Linux install does not present the same issue

File system is being instantiated more than once in the code, breaking the test file emulator

After project init and generate new Test package, the package type is not correct.
is being set as "Test" instead of "Tests"

The build of Data should check if the DEEs can be compiled. Right now someone can change a DEE merge with development and then the fact the DEE is not compilable will only be caught by a Business PR.

Also Business Compiling should be explicitly be project and not by solution, because right now it's compiling the DEEs even though they are not part of the Business package

We have some packages that assemble shouldn't take care, because we have the assumption that packages are already installed.
In case that are not installed the installation will fail.

Currently, the cli is using the Powershell Installer approach to generate Master Data packages. Starting with MES v8.2, all need functionality is supported by the Deployment Framework. So, migrate and remove the Powershell Installer from the cli.

This is a breaking change.

The JsonIgnore tag that was placed so it would not serialize certain properties is impacting the property deserialization

Requirement

• Gather all packages needed for installation based on a root CmfPackage

Assumption

• This command should run on a git repo with a cmfpackage.json

Arguments/Options

• ciRepo
• Continuous Integration repo (can be a folder or a url)
• repos
  • List of repositories (can be a folder or a url)
• outputDir
  • Output directory where the packages will be put

Logic

• Load root CmfPackage
• if PackageType is not root, throw exception
• Call method LoadDependencies
  • with this we should all the local and remote packages
  • if a local package is not found locally or in repository, an exception should be thrown
• Copy all packages with Location=Local that do not exist in repos list from ciRepo to outputDir
• Generate json file with all dependencies (Id@Version-Uri) that were not copied

This option in the majority of the cases is called with this option as true, based on that the defaultvalue of skipDependencies option on pack command should set as true.

when using the bump command with --all option if the dependency packages versions doesn't match the error is pointing to the wrong version.

repro steps:
have a root package with a dependency:
"dependencies": [ { "id": "PackageA", "version": "1.0.0" }]

have the package with another version:
{ "packageId": "PackageA", "version": "1.0.1", }

running the cmf bump --all:

Example:
My package depends on a package that has to be installed in the system, but I don't want to ship it in the same package as my feature package

CMF pack
if (!dependencyFound) { if (dependency.Mandatory) { throw new CliException(string.Format(CliMessages.MissingMandatoryDependency, dependency)); } else { Log.Warning(string.Format(CliMessages.MissingMandatoryDependency, dependency)); } }

When invoking GetContentToPack it is creating target folders if they don't exist. When JSON validator was invoking this it is creating a folder in the pack.

Hi all,

It would be great to have a command that would check my business dependencies (internal or remote) and deploy them to my local environment. This way, when generating the LBOs I would know everything is consistent

Hi,

If I am involved in two different projects that use different cli versions, what's your suggestion on how to handle it? v2 introduces breaking changes from v1, so when I install it locally it may affect the project that still depends on cli v1.

Thank you.

for standardization proposes all commands, should always run in the scope of the package in the working directory.

This cause the previous "magic" cast from String to DirevtoryInfo done by System.CommandLine to return nulls. We need to implement parseArgument in these cases

If the PackageType is equal to Data the Build command should validate the json and xml files are valid

When running cmf init without an output directory, the following error is shown:

"Rerun the command and pass --force to accept and create."

However, documentation does not mention this

Currently pack command is not logging the final path of the package

Help in new command is missing artifacts folder

The first action on the CMF HTML scaffolding should be validate that the path to the html package is correctly mounted

i.e cmf new html --version 1.0.0 --htmlPackage D:\packages\Cmf.Presentation.HTML.8.2.2.zip
First action should be validate, this exists -> D:\packages\Cmf.Presentation.HTML.8.2.2.zip

Some IoT specific commands were placed incorrectly in the command tree. These should be changed to:
bumpIoTConfiguration -> bump iot configuration
bumpIoTCustomization -> bump iot customization

The package dependency tree is being used for ls, pack and publish with some slight differences. This logic is also mixed with the actual command execution, e.g. we are building the tree while we are packing.
To help with testing and simplifying our logic, the dependency tree should be built first and be usable by all commands

The MDL GUI supports loading Master Data archives in the format:

• <root>
  • masterdatafile.<xlsx|json|xml>
  • [dependency folders]

The DF packages support multiple master data files, so that we can ship this by feature. As such, an end user that would need to manually load Master Data archives needs to transform the DF package to several MD archives.

Legend:

• ❗ -> needs rework
• ➕ -> in the backlog
• 🔗 -> group only, command is a no-op
• ☑️ -> completed

Included

• build <- build a package
  • help 🔗
    • generateBasedOnTemplates <- generate help index markdown files
    • generateMenuItems <- generate help menu
• bump <- bump package versions
  • iot 🔗
    • configuration
    • customization
• ☑️ ls <- list package tree
• local 🔗 [to be moved to plugin]
  • generateLBOs <- generate LBOs in your local environment
  • getLocalEnvironment <- setup local environment
• pack <- create packages
• publish <- publish packages for release
• ☑️ assemble <- gather all packages needed for installation
• ☑️ init <- initialize a new repository structure
• ☑️ new <- scaffold new packages
• ➕ masterdata 🔗 [this is post v2]
  • ➕ extract <- extract a Master Data package into individual archives suitable for the Master Data Loader GUI

cmf init documentation states the following:

Usage:
cmf init [options] [ []]

Arguments:

[default: Cmf.Custom.Package]
Working Directory [default: .]

However, if I try, for example, the following:

cmf init "MyProject"
I have an error because --customPackageName is mandatory

Maybe also the publish command

Would be great to have a command that will check the dependecies and the project itself and update the GUI package json cmfLinkDependencies to the correct relative paths

Currently, for all commands the only way of exiting with a non-zero exit code is by throwing an exception, which polutes the logs quite a bit. In dotnet/command-line-api, it should be possible for the handler to provide the exit code, but our handlers return void. This should possibly be refactored.
Also, there is no reason for our handlers to be public, though this has been a convention since the beginning.

Asssemble Command Generated Dependencies File is Adding Local Data Package, when it should add only remote

when a new version is available of the cli or any of the installed plugins, a notification should appear to the user.
something like:
a new version of cmf-cli is available: URL

Hi,

I'm not sure I did something wrong, but after running cmf init, it generated the GlobalVariables.yml file without the values filled.

Trying to fill them, I searched for documentation on what it means, but I couldn't find anything. There are some fields that are self-explanatory, but I don't know what these mean:

CmfCliRepository (I looked for an example and the value should be 'https://registry.npmjs.com')
CmfPipelineRepository
CmfPipelineVersion

Thank you and best regards.

As plugins to the cli start getting published, as a user I want a way, like a cli command, to search for available plugins.

As a reminder, even manually (i.e. not searchable/published) installed plugins will always work. To have a cmf-cli plugin, just place a cmf- binary somewhere in your PATH. Check the PluginCommand for more details on which formats are supported.

The current design draft (which can undergo changes when implementing) is:

• plugins are published in npmjs.com
  • they should be published with the keyword cmf-cli-plugin
• cli should provided a new command search
  • this command should use the npmjs.com API to find all packages with the keyword specified above
  • packages under the @criticalmanufacturing organization should be treated as official plugins and should be distinguished in the output of the search command
  • installation should then be done with npm install -g, there's no need to add a wrapper around this

We should use the new assemble command in CI-Publish.
The dependencies file should be included in the Configurations artifact.
CI-Release must obtain the file from the artifact and use it to download all dependencies: this is necessary, at least, for DevOps Center installations

• for these, the dependencies must be placed in the boot packages share/volume.
• After we place the dependencies, the release candidate packages (the main release artifact) must also be placed in boot packages.
• After, we also need to add the FullBackup package

As a user, I want to scaffold a new repository structure, step by step. This includes:

• initialize a repository (if needed. A repository is simply a collection of features with a local environment)
• create a new local environment
• creating a feature
• create layer solutions in a feature
  • business
  • html
  • data
  • help
    (...)

The basic case for the global cli installations is currently not working. Steps to reproduce:

1. install Node using the official MSI (I tested with version 14 but seems to happen in other versions)
2. install cli globally: npm i -g @criticalmanufacturing/cli
3. set env variable or run with DEBUG=cmf:*
4. run cmf -h

No help menu is shown because the node shim that invokes the cli binary thinks it was installed locally and not globally.

This is due to a bug with sindresorhus/is-installed-globally. In this case, npm is installed inside %APPDATA% and not under the node prefix, which by default is C:\Program Files\nodejs but is-installed-globally does not account for this scenario.

A simple fix could be checking if the node shim is inside %APPDATA%.

Bump should be locally scoped.

Bump should only look at the specific package that is executed.

deprecate --all option

Assemble command is always assuming include test false. Assemble needs to retrieve the test packages that are explicitly part of the CmfPackage.json

Instead of throw an error: https://github.com/criticalmanufacturing/cli/blob/4b1b5ab8836436f70ca281cf5b6227f1d4f15597/cmf-cli/Objects/CmfPackage.cs#L264, we should force the Data packages to set isUniqueInstall as true.

Some shells (e.g. Powershell) interpret the double dash (--) in command arguments. Currently the plugin command expects plugin parameters to be specified after a double dash, like cmf [cli options] -- [plugin options].
However, because some shells interpret and then strip the double dash, the invocation needs to actually be something like cmf [cli options] '--' [plugin options] which isn't ideal.
As the cli options are currently not used for the plugin commands, the double dash requirement could, in theory, be dropped. However, System.CommandLine expects any command options to be explicitly declared, so a work around would be needed.
To resolve this, we'd need to

1. support invoking a plugin without the double dash
2. make sure the help menu works

When deploying more than one help package to the same documentation site, there are collisions with the menu item IDs, as they are fixed (and hardcoded). This needs to change to include the package id as part of the menu group and items ids.

to add new strategies to SecurityPortal, cli needs to support this new PackageType.
manifest.xml example:

  <packageType>Generic</packageType>
  <targetDirectory>SecurityPortal</targetDirectory>
  <targetLayer>securityportal</targetLayer>