I ran sasjs cbd and the app was not deployed - yet nothing shown in the log results:

The sasjs run command still uses the old token mechanism that requires manual intervention to input an auth code.
If we can migrate this over to the mechanism used by the other commands, we can use the token stored in the .env file to run SAS code.

The log is currently output to the console, and not saved anywhere. It'd be good to be able to store it in a file.

After auto-deploying the service pack, it is useful to run the Deploy scripts, eg for the following (common) example:

• Deploy service pack services
• Execute a 'create database' service
• run a shell command to ftp the frontend to the web server

Fix add global target command to match local target

We should run a series of tests to make sure the commands are still working, eg:

sasjs v

sasjs create test1

sasjs create test2 -t minimal

sasjs create test3  -t react

sasjs create test4 -t angular

sasjs create test5 -t sasonly

cd test5

sasjs cb

The following was returned from the CLI:

➜  /tmp sasjs context create -s SharedCompute.json -t globviya
An error has occurred when processing context. Forbidden. Check your permissions and user groups. 
traceId: f3020dddb774e035,path: /compute/contexts
:q!

the issue was that the CLIENT was generated without the correct scopes. We should update the warning text to:

An error has occurred when processing context. Forbidden. Check your permissions and user groups, and also the scopes granted when registering your CLIENT_ID.

We need to import the ability to create / delete folders using the cli

sample commands

sasjs createfolder /Public/folder

sasjs deletefolder /Public/folder

sasjs movefolder /Public/source/childFolder /Public/parentTarget

• Move command line parsing logic to the centralized utility.

• Standardize command line flags.

• Use Yargs for parsing.

We need a command that will trigger a job, and immediately return. This is unlike:

• sasjs request (runs a job as a web service and waits for a _webout response)
• sasjs run (executes arbitrary code inside a SAS session, and waits for the response)

Proposed syntax:

sasjs job execute <jobpath> [additional arguments]

Additional optional arguments may include:

--target (alias -t) - the target environment in which to deploy the services. If not specified, the first target will be used instead.
--wait (alias -w) - the cli will wait for the job to finish. Default false
--output (alias -o) - the cli will output a JSON file with the returned attributes of the job object.

The CLI / adapter will simply trigger the job, on it's default context, and return immediately once the job has started.

Future potential use cases for this command:

• sasjs job create
• sasjs job export
• sasjs job delete
• sasjs job edit
• sasjs job compile -> like compiling a service, but without the web macros as precode

We need a new command:

sasjs request

This is in order to run existing, deployed SAS services. It will take the same params as the adapter, service location, data (path to a json file), and config (if overriding).

We will then get as output the following files:

[servicename].json -> the output of the service
[servicename].log -> the log

This output will go in the sasjsbuild folder if running in a local project, else the current directory if global. At a later date we should set a default in the config for these results (and same for sasjs run)

We need a template for adding just the SAS component to a frontend project.

the command will be sasjs create [name] -t sasonly

• if [name] is missing, it should be created in the current directory (this should be true for the other templates also)
• the folowing sasjs subfolders will be created: [macros,build,db,services]
• the sasjs/services/common/appinit.sas will be created
• npm install @sasjs/core will execute
• the .gitignore will be created or updated
• a minimal sasjsconfig.json will be created, with an empty targets array

For now we need deploy action. In future we will have export and create.

Parameters

-t / --target - accepts a target string. (optional)
-s / --source - accepts a json file containing services to be deployed. (required)

Example call

sasjs servicepack deploy -t sampleTarget -s sampleFile.json

It should work with both global and local targets.

The feature should also be fully documented.

when running sasjs add for a LOCAL config we should also give an opportunity to (optionally) add the appLoc

The default value should be /Public/app/[TARGETNAME]

adding deployServicePack:true to my target config enabled the deploy, although it asked for an authorization_code (this happened already with sasjs add so shouldn't have happened twice)

We need the following commands, which are based on their equivalents in the adapter

sasjs context create

sasjs context edit

sasjs context delete

We could change the names of the commands if it makes sense. OR we figure out a generic way to run the sasjs functions.

The edit part depends on #sasjs/adapter#73

Now that we have commands (such as sasjs servicepack and sasjs request that run globally, and require / can make use of appLoc, we should integrate this with the sasjs add interface.

Definition of done: When adding a GLOBAL target with sasjs add a prompt is made for a default appLoc which is then saved along with the target details in .sasjsrc.

When streamWeb:true and serverType is SAS9 we should base64 encode the JS and CSS files into SAS.

This is because JS and CSS files can contain UTF-8 characters that are not supported in customer environments that use WLATIN1.

For Viya, the encoding is always UTF-8 so the conversion is not needed.

The downside of the conversion is much higher file sizes (4x) however these assets are cached by the browser so the impact is only felt once on startup.

We should invoke these using JS64 and CSS64 in the function, eg:

%sasjsout(JS64)

For security, the authinfo properties should not be inserted into the sasjsconfig.json file.

When running sasjs add in LOCAL the .env file should contain the following:

• access_token
• refresh_token
• client_id
• client_secret

When running in global, they can go in the .sasjsrc file.

In terms of the CLIENT and SECRET, these could also go in the target (two new properties, client_id and client_secret). The values in the .env file would take precedence over those in the target.

.env

The project would have a main .env file as a fallback for all local targets. The primary file will be .env.[targetname].

credentialsFile

The sasjsconfig.json file will also have an optional property ("credentialsFile":"../../path/to/creds.file",) that overrides all implicit settings and states explicitly where the credentials are sourced from.

When running a sasjs command, the order of arguments should not matter - i.e. the result should be the same regardless of the order of the parameters.

Do not choose any of types of access.

it would be easier to type a number than a context name in the screen below:

The "useMacroCore": true, argument should default to true if omitted from the package.json

sasjs run should be able to use access tokens from the global .sasjsrc file to run SAS code.

• For SCOPE let's default to 1 (local)

• the next option should be Please pick a target server type and default to 1. SAS Viya

• the target name can then default to the server type (eg sas9 or viya). There should be a check to avoid duplicating any existing server types in sasjsbuild/sasjsconfig.json (if it exists)

• "Please enter a server URL:" -> Please enter a target server URL (including port, if relevant):

https://github.com/macropeople/sasjs-cli

We should leave some pointers though, so users can find the new one

https://www.npmjs.com/package/sasjs-cli

When setting up a repo, and adding a correct url, and doing a sasjs d to a viya target, the messages suggest that the root folder does not exist.

However in fact, the client / secret were not provided and so the session is unauthenticated.

When running the tests, we are installing the latest version of the CLI from NPM.
Instead, we should be testing against the current version from sources with any new changes.

Investigate how this is currently handled.

It'd be good if we can implement the usage of quotes to pass in arguments with multiple words.

We need to address the following warnings when installing sasjs cli

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: this library is no longer supported

The -t on sasjs run should be optional - it would be nice if it would just pick the first target

I expected this to crash as I hadn't sasjs add'd however the message should have been more helpful

Definition of done: helpful error messages when attempting to run code in a misconfigured state

Builds should run prettier to check code style.

Quite regularly when upgrading the CLI using npm i -g @sasjs/cli@latest I will see that the version number does increase, so I believe I have the latest CLI, however - the actual functionality does not appear.

Every time I must perform an action such as:

rm -rf /home/vrh/.nvm/versions/node/v12.16.1/lib/node_modules/@sasjs

and then re-install.

We need to figure out how we can enable consistent CLI upgrades.

As demonstrated here:

Steps:

sasjs create demo -t sasonly
cd demo
sasjs add  #follow the steps
sasjs run package.json -t [target]

I expected it to error (the package.json is not a valid sas file) however the SAS log should have been returned (or an error handler should have provided more explicit details of what went wrong)

The issue appears when target name has -t entry

The react seed app makes use of a manifest.json which doesn't currently get served in the stream approach

We should support the JSON streamed file type eg in a link like the below:

    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />

we should refactor to fit in with the existing context functions

Related issue #73

On SAS 9, the most reliable way to do this is using the batch tools. This will necessitate the use of an SSH connection to SAS.

Additional variables will also be needed in the .env file:

• SSH_SERVER (to default to serverUrl)
• SSH_KEYFILE (to default to ~/.ssh/id_rsa)
• SSH_USER (to default to SAS_USERNAME)
• META_SERVER (to default to serverUrl)
• META_PORT (to default to 8561)
• SAS_TOOLS (to default to /opt/sas/sas9/SASHome/SASPlatformObjectFramework/9.4/tools)

The SAS_USERNAME & SAS_PASSWORD will have been captured from the sasjs auth command.

Running the sasjs folder delete command for a SAS9 target will result in the following:

1. Extract SAS_USERNAME and de-coded SAS_PASSWORD from .env.target file
2. Prepare script for SSH execution eg as follows:

#!/usr/bin/env bash
cd "$SAS_TOOLS"
./sas-delete-objects \\
  "$PATH_TO_DELETE" \\
  -host $META_SERVER -port $META_PORT \\
  -user '$SAS_USERNAME' -password "$SAS_PASSWORD" \\
  -deleteContents 2>&1

3. Execute the script (first making sure the batch tool exists) and fetch the log

There should be no trace of the de-coded SAS_PASSWORD on either the local or remote system.

When adding a new target, the following is returned at the end:

Target successfully added!

We should expand this to also show the location of the file in which the target was added, for clarity.

To facilitate the automated deployment of apps such as data controller on SAS Viya we need the ability to auto-create server Contexts on which to run the Job Execution services.

The inputs for this would be:

• contextname - max 40 chars
• sharedaccount - a userid for the runServerAs property
• autoexec - a string of code lines (this gets executed by SAS on startup)

The following properties should be hardcoded (for now):

• Launcher Context - SAS Job Execution launcher context
• Identities - Authenticated Users
• reuseServerProcesses attribute - true

More info:

• https://documentation.sas.com/api/docsets/calcontexts/3.5/content/calcontexts.pdf?locale=en
• https://developer.sas.com/apis/rest/Compute/#create-a-context-definition

Context should be exported to contextName.json in the current folder.
command example: sasjs context export <contextname> -t targetName

If the user wishes to add a local config, but he is not in an existing repository, we should deploy a "sasonly" template (#68) to avoid the situation below

currently when installing react, angular or minimal templates we leave behind a .git folder. This is a problem for two reasons:

1 - we don't actually want users to push to that repo
2 - it causes problems when running the command within existing repos

Definition of done - the .git folder is removed following the git clone for template installs