Merge branch 'next' into tsoIssueCommand

.github/workflows/audit.yml

@@ -6,8 +6,8 @@ on:
       - master
       - zowe-v1-lts
       - next
-  # schedule:
-  #   - cron: '0 10 * * *'
+  schedule:
+    - cron: '0 10 * * *'
 
 jobs:
   audit:
@@ -37,4 +37,4 @@ jobs:
 
     - name: Check Secrets SDK Vulnerabilities
       working-directory: packages/secrets/src/keyring
-      run: cargo audit --deny warnings
+      run: cargo audit --deny warnings --ignore RUSTSEC-2024-0370

.github/workflows/auto-comment.yml

@@ -3,6 +3,8 @@ name: Zowe CLI Auto Responder for New Issues
 on:
   issues:
     types: labeled
+permissions:
+  issues: write
 
 jobs:
   processLabelAction:

.github/workflows/rust-cli-publish.yml

@@ -9,6 +9,9 @@ on:
     - 'zowex/**'
     - '.github/workflows/rust-cli*.yml'
 
+permissions:
+  contents: write
+
 jobs:
 
   release:

.github/workflows/update-project.yml

@@ -12,6 +12,9 @@ env:
   PR_STATUS_DRAFT: 'In Progress'
   PR_STATUS_READY: 'Review/QA'
 
+permissions:
+  pull-requests: write
+
 jobs:
   update-project:
     name: Move project item

.github/workflows/zowe-cli.yml

@@ -164,6 +164,10 @@ jobs:
     if: github.event_name == 'push' && github.ref_protected
     needs: test
     runs-on: ubuntu-latest
+    permissions:
+      issues: write
+      contents: write
+      pull-requests: write
 
     steps:
     - name: Checkout

CONTRIBUTING.md

@@ -4,6 +4,7 @@ This document is a living summary of conventions and best practices for developm
   - [SIGN ALL OF YOUR GIT COMMITS](#sign-all-of-your-git-commits)
   - [Understanding Packages and Plug-ins](#understanding-packages-and-plug-ins)
   - [Pull Requests](#pull-requests)
+  - [Dependencies](#dependencies)
   - [Contributing to Core Functionality](#contributing-to-core-functionality)
   - [General Guidelines](#general-guidelines)
   - [Changelog Update Guidelines](#changelog-update-guidelines)
@@ -61,7 +62,7 @@ For more information and guidelines for setting up your project, see [Packages a
 
 Determine if the infrastructure enhancement applies to Zowe CLI or Imperative CLI Framework, or if it is best suited as a plug-in to the core.
 
-Zowe CLI is built on [Imperative CLI Framework](https://github.com/zowe/imperative/wiki). Most Zowe CLI core functionality is contained within the framework. Work in, or submit issues to, the Imperative CLI Framework repository when you want to enhance the following core functionalities:
+Zowe CLI is built on [Imperative CLI Framework](https://github.com/zowe/zowe-cli/wiki). Most Zowe CLI core functionality is contained within the framework, such as:
 
   - REST client
   - Logging
@@ -75,9 +76,18 @@ Zowe CLI is built on [Imperative CLI Framework](https://github.com/zowe/imperati
 Consider the following when you interact with pull requests:
 
 - Pull request reviewers should be assigned to a same-team member.
-- Pull requests should remain open for at least 24 hours, or until close of business next business day (accounting for weekends and holidays).
+- Pull requests should have at least 2 approving reviews before merging.
 - Anyone can comment on a pull request to request delay on merging or to get questions answered.
 
+## Dependencies
+
+The CLI and Zowe plug-ins use strict version numbers for dependencies.
+Any SDKs should not pin dependencies unless it is absolutely required in order to function.
+  - `^` should be used to specify any dependency with the same major version.
+  - `~` should be used to specify any dependency with the same minor version.
+
+For Zowe organization repositories, all dependencies must be compatible with the EPL-2.0 license.
+
 ## General Guidelines
 
 The following list describes general conventions for contributing to Zowe CLI:
@@ -89,14 +99,18 @@ The following list describes general conventions for contributing to Zowe CLI:
 - Throw ImperativeError (or perhaps a wrapping of these) instead of throwing Error objects for automatic logging and node-report captures.
 - Provide adequate logging to diagnose problems that happen at external customer sites.
 - Avoid using/referencing to `zowe` or `Zowe CLI` within help, source file names, and errors - this name is subject to change. For example use `cli` instead.
-- Keep "packages" small and independent without cross dependencies (e.g. `zosjobs` logically should not depend on `zosfiles` package)
+- Keep "packages" small and independent, without cross dependencies whenever possible (e.g. `zosjobs` logically should not depend on `zosfiles` package, but may rely on `core` for core z/OSMF functionality)
   - When a package is dependent on another package, import the through the dependent package's interface (`index.ts`)
   e.g. `packages/zosjobs/src/GetJobs.ts` will import the `rest` package via:
     ```typescript
-       import { ZosmfRestClient } from "../../../rest";
+       import { ZosmfRestClient } from "@zowe/core-for-zowe-sdk";
     ```
       NOT via:
     ```typescript
+    import { ZosmfRestClient } from   "../../../rest";
+     ```
+      OR via:
+    ```typescript
     import { ZosmfRestClient } from   "../../../rest/src/ZosmfRestClient";
      ```
 - Make classes small, logical pieces (e.g. instead of 1 `Jobs` class to hold all Job's APIs, we have `GetJobs`, `SubmitJobs`, `DeleteJobs`, etc...)
@@ -199,11 +213,11 @@ Open an issue in the [docs-site repository](https://github.com/zowe/docs-site) i
 
 - When contributing **a plug-in**, we recommend that you provide the following:
 
-  - End-user documentation on the Zowe Doc Site so that users can learn about your plug-in. Use existing plug-in topics as a model.
+  - End-user documentation on the Zowe Docs site so that users can learn about your plug-in. Use existing plug-in topics as a model.
 
-  - A readme.md file within the plug-in repository that contains information for developers (overview, how to build from source, and how to run tests, at minimum). For example, see [the CICS plug-in readme](https://github.com/zowe/zowe-cli-cics-plugin#zowe-cli-plug-in-for-ibm-cics).
+  - A readme.md file within the plug-in repository that contains information for developers (overview, how to build from source, and how to run tests, at minimum). For an example, see [the CICS plug-in readme](https://github.com/zowe/cics-for-zowe-client/tree/main/packages/cli#IBM-CICS-Plug-in-for-Zowe-CLI).
 
-  - a CONTRIBUTING.md file within the plug-in repository that lists specific considerations for contributing code to your plug-in (if any), and also links to the core CLI contribution guidelines. For an example, see [the CICS plug-in contribution guidelines](https://github.com/zowe/zowe-cli-cics-plugin/blob/master/CONTRIBUTING.md).
+  - A CONTRIBUTING.md file within the plug-in repository that lists specific considerations for contributing code to your plug-in (if any), and also links to the core CLI contribution guidelines. For an example, see [the CICS plug-in contribution guidelines](https://github.com/zowe/cics-for-zowe-client/blob/main/CONTRIBUTING.md).
 
 - When contributing **code/functionality to the core CLI**, we recommend that you provide the following:
 
@@ -213,7 +227,7 @@ In addition to external documentation, please thoroughly comment your code for f
 
  ### JS Documentation
 
-- Use jsdoc annotations - [document this](https://marketplace.visualstudio.com/items?itemName=joelday.docthis) makes extensive use of jsdoc tags.
+- Use jsdoc annotations
   - Common tags to use, `@static`, `@memberof`, `@returns`, `@params`, `@class`, `@exports`, `@interface`, `@types`, `@throws`, `@link`
 - CLI auto-generated documentation is created via command definitions
 - [tsdoc](https://typedoc.org/) is used to generate html documentation

__tests__/__packages__/cli-test-utils/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zowe/cli-test-utils",
-  "version": "8.0.0-next.202408301809",
+  "version": "8.0.0-next.202409111528",
   "description": "Test utilities package for Zowe CLI plug-ins",
   "author": "Zowe",
   "license": "EPL-2.0",
@@ -43,7 +43,7 @@
   "devDependencies": {
     "@types/js-yaml": "^4.0.9",
     "@types/uuid": "^10.0.0",
-    "@zowe/imperative": "8.0.0-next.202408301809"
+    "@zowe/imperative": "8.0.0-next.202409111528"
   },
   "peerDependencies": {
     "@zowe/imperative": "^8.0.0-next"

docs/CommandFormatStandards.md

@@ -59,7 +59,7 @@ Refer to the following guidelines when writing descriptions for syntax segments
 
 - The `summary` is a one line, short description. This appears in the list of sub-segments on online help pages (for example, Zowe root help lists the groups with their short descriptions. Zowe group help lists the actions with their descriptions.
 
-    - Do NOT include punctuation at the end of a summary description for consistency.
+    - For consistency, do NOT include punctuation at the end of a summary.
 
 - The full `description` explains the purpose, intent, & usage of the group, action, object, or option. Ideally, include use cases that apply so that people understand the practical value. There is some tension between clarity and length. Extremely long descriptions can clutter the interface, but users want to know what they can accomplish with a given command. Some end users have indicated that they struggle to understand what the CLI is capable of and how they might use it, so good descriptions are essential.
 
@@ -81,9 +81,9 @@ Research and usability testing has revealed that examples are the single most im
 
 - Positional arguments are a special kind of option. They are values/arguments entered that have an implicit option name and are usually entered immediately after the `object` (for example, the file name in the `zowe zos-files list dataset` command). These are usually required arguments. A single positional argument is most common but some commands have multiple positional arguments that are entered space-separated. We do not advise having multitple positional arguments because then the user must type several values in a row in the correct order, which can be error prone and hard to understand the proper syntax. Where there appears to be a need for multiple positional arguments, consider adding formal `option` names and make them required. 
 
-- Required options are listed under a Required Options section in the help. User research and usability testing have shown that statements explaining which options are required is among the most useful information in the online help pages, so it is important to write good descriptions and include these in the examples.
+- Required options are listed under a `Required Options` section in the help. User research and usability testing have shown that statements explaining which options are required is among the most useful information in the online help pages, so it is important to write good descriptions and include these in the examples.
 
-- Non-required options are listed under an Options section in the help.
+- Non-required options are listed under an `Options` section in the help.
 
 - The help may include other categories of options for connecting to a service such as z/OSMF (for example, `--password`), setting profiles, and global options (for example,`response-format-json`)
 
@@ -93,11 +93,11 @@ Research and usability testing has revealed that examples are the single most im
 
 - Dependencies between options can exist (if you specify one, you must specify the other, for example). This can introduce usability problems. The dependencies with other options should be noted in the option description.
 
-- The arguments/values for an `option`  can sometimes take wildcards (for example, a data-set name). The wildcard symbol is generally the asterisk * character. When building commands, consider using asterisk as the standard.
+- The arguments/values for an `option` can sometimes take wildcards (for example, a data set name). The wildcard symbol is generally the asterisk (*) character. When building commands, consider using asterisk as the standard.
 
 - The arguments/values can sometimes include quotes and can be a safer way to type the command. When writing examples, it is advisable to show arguments in quotes.
 
-- Some options take array values. The standard format is space separated. For more information, see [ICommandPositionalDefinition.ts](https://github.com/zowe/imperative/blob/master/packages/cmd/src/doc/option/ICommandPositionalDefinition.ts).
+- Some options take array values. The standard format is space separated. For more information, see [ICommandPositionalDefinition.ts](https://github.com/zowe/zowe-cli/blob/master/packages/imperative/src/cmd/src/doc/option/ICommandPositionalDefinition.ts).
 
 ## Abbreviated Command Structure 
 

docs/DevelopmentTips.md

@@ -2,27 +2,10 @@
 
 ## Contents
 
- - [Linking Imperative from source](#linking-imperative-from-source)
  - [Debugging in VS Code](#debugging-in-vs-code)
  - [Profiling with `pprof`](#profiling-with-pprof)
  - [Using Development Mode](#using-development-mode)
 
-## Linking Imperative from source
-
-If you make changes in a local copy of Imperative and want to test them in Zowe CLI, you need to replace the `node_modules/@zowe/imperative` directory with a symlink to the Imperative repo.
-
-To set up this symlink, run the following command at the top level of the Zowe CLI repo:
-
-    npm run link:imperative
-
-The first time this command is run, you may see a warning that "Symlink wanted name was occupied by directory or file" which is safe to ignore.
-
-This command must be repeated to recreate the link after running `npm install` or any other command that updates dependencies in the `node_modules` folder.
-
-**Note:** The command assumes your Imperative repo is located in an `imperative` folder alongside your `zowe-cli` folder. If it is located somewhere else, run the command like this:
-
-    npm run link:imperative -- <pathToImperativeRepo>
-
 ## Debugging in VS Code
 
 Create a launch configuration like the following. You can have as many launch configurations as you want, each with their own name and set of arguments.