arikon · May 30, 2020 20:42
diff --git a/common--config--deploy-scenarios--sync-ofd-ru-recipes.jsonc b/common--config--deploy-scenarios--sync-ofd-ru-recipes.jsonc
 /**
 * This configuration file defines a deployment scenario for use with the "rush deploy" command.
 * The scenario files are located under the "common/config/deploy-scenarios" folder.
 * For full documentation, please see https://rushjs.io
 */
 {
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/deploy-scenario.schema.json",

  /**
   * Specify the name of the Rush project to be deployed. The name must be a full package name
   * as declared in rush.json.  If you want to include other projects that are not dependencies,
   * add an entry for your main project to the "projectSettings", then use the "additionalProjectsToInclude" setting.
   *
   * The "deploymentProjectNames" array must contain exactly one project, unless "enableSubdeployments" is true;
   * see documentation for that setting for details.
   */
  "deploymentProjectNames": [
    "@smart-oil/sync-ofd-ru-recipes"
  ],

  /**
   * Subdeployments are an optional feature that enables multiple deployments to be prepared by a single
   * invocation of "rush deploy". In this mode, more than one name can be specified for "deploymentProjectNames".
   * For each entry, a subdeployment folder will be created under the "rush deploy" target folder.
   * (The folder name can be customized using the "subdeploymentFolderName" project setting.)
   * Each subdeployment folder will receive its own copy of the named project and its associated dependencies.
   *
   * The default value is false.
   */
  "enableSubdeployments": false,

  /**
   * When deploying a local Rush project, by the "devDependencies" are normally excluded.
   * Set this to "true" to include them.
   *
   * The default value is false.
   */
  // "includeDevDependencies": true,

  /**
   * When deploying a local Rush project, normally the .npmignore filter is applied so that Rush only copies
   * files that would be packaged by "npm pack".  Setting "includeNpmIgnoreFiles" to true will disable this
   * filtering so that all files are copied (with a few trivial exceptions such as the "node_modules" folder).
   *
   * The default value is false.
   */
  // "includeNpmIgnoreFiles": true,

  /**
   * Specify how symlinks will be created in the deployed folder:
   *
   * - "default": Create the symlinks after copying the files; this is the default behavior.
   * - "script": A Node.js script called "create-symlinks.js" will be written.  When executed, this script will
   *   create the symlinks described in the "deploy-metadata.json" output file.
   * - "none": Do nothing; some other tool may create them later.
   */
  // "symlinkCreation": "script",

  /**
   * Customize how Rush projects are processed during deployment.
   */
  "projectSettings": [
    // {
    //   /**
    //    * The full package name of the project, which must be declared in rush.json.
    //    */
    //   "projectName": "@my-scope/my-project",
    //
    //   /**
    //    * This optional setting is only relevant when "enableSubdeployments" is true.  It customizes the
    //    * subdeployment folder name.  If omitted, the default subdeployment folder name will be the
    //    * package name without its NPM scope.
    //    */
    //   // "subdeploymentFolderName": "my-proj",
    //
    //   /**
    //    * A list of additional local Rush projects to be deployed with this project (beyond the package.json
    //    * dependencies).  Specify full package names, which must be declared in rush.json.
    //    */
    //   "additionalProjectsToInclude": [
    //     // "@my-scope/my-project2"
    //   ]
    // }
  ]
 }
diff --git a/info.md b/info.md
diff --git a/rush.jsonc b/rush.jsonc
 /**
 * This is the main configuration file for Rush.
 * For full documentation, please see https://rushjs.io
 */
 {
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

  /**
   * (Required) This specifies the version of the Rush engine to be used in this repo.
   * Rush's "version selector" feature ensures that the globally installed tool will
   * behave like this release, regardless of which version is installed globally.
   *
   * The common/scripts/install-run-rush.js automation script also uses this version.
   *
   * NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"
   * path segment in the "$schema" field for all your Rush config files.  This will ensure
   * correct error-underlining and tab-completion for editors such as VS Code.
   */
  "rushVersion": "5.23.6-pr1898.0",

  /**
   * The next field selects which package manager should be installed and determines its version.
   * Rush installs its own local copy of the package manager to ensure that your build process
   * is fully isolated from whatever tools are present in the local environment.
   *
   * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion".  See the Rush documentation
   * for details about these alternatives.
   */
  "pnpmVersion": "5.0.2",

  // "npmVersion": "4.5.0",
  // "yarnVersion": "1.9.4",

  /**
   * Options that are only used when the PNPM package manager is selected
   */
  "pnpmOptions": {
    /**
     * Specifies the location of the PNPM store.  There are two possible values:
     *
     * - "local" - use the "pnpm-store" folder in the current configured temp folder:
     *   "common/temp/pnpm-store" by default.
     * - "global" - use PNPM's global store, which has the benefit of being shared
     *    across multiple repo folders, but the disadvantage of less isolation for builds
     *    (e.g. bugs or incompatibilities when two repos use different releases of PNPM)
     *
     * RUSH_PNPM_STORE_PATH will override the directory that will be used as the store
     *
     * In all cases, the store path will be overridden by the environment variable RUSH_PNPM_STORE_PATH.
     *
     * The default value is "local".
     */
     "pnpmStore": "local",

    /**
     * If true, then Rush will add the "--strict-peer-dependencies" option when invoking PNPM.
     * This causes "rush install" to fail if there are unsatisfied peer dependencies, which is
     * an invalid state that can cause build failures or incompatible dependency versions.
     * (For historical reasons, JavaScript package managers generally do not treat this invalid
     * state as an error.)
     *
     * The default value is false to avoid legacy compatibility issues.
     * It is strongly recommended to set strictPeerDependencies=true.
     */
    // "strictPeerDependencies": true,


    /**
     * Configures the strategy used to select versions during installation.
     *
     * This feature requires PNPM version 3.1 or newer.  It corresponds to the "--resolution-strategy" command-line
     * option for PNPM.  Possible values are "fast" and "fewer-dependencies".  PNPM's default is "fast", but this may
     * be incompatible with certain packages, for example the "@types" packages from DefinitelyTyped.  Rush's default
     * is "fewer-dependencies", which causes PNPM to avoid installing a newer version if an already installed version
     * can be reused; this is more similar to NPM's algorithm.
     *
     * After modifying this field, it's recommended to run "rush update --full" so that the package manager
     * will recalculate all version selections.
     */
    // "resolutionStrategy": "fast",

    /**
     * If true, then `rush install` will report an error if manual modifications
     * were made to the PNPM shrinkwrap file without running "rush update" afterwards.
     *
     * This feature protects against accidental inconsistencies that may be introduced
     * if the PNPM shrinkwrap file ("pnpm-lock.yaml") is manually edited.  When this
     * feature is enabled, "rush update" will append a hash to the file as a YAML comment,
     * and then "rush update" and "rush install" will validate the hash.  Note that this does not prohibit
     * manual modifications, but merely requires "rush update" be run
     * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
     *
     * To temporarily disable this validation when invoking "rush install", use the
     * "--bypass-policy" command-line parameter.
     *
     * The default value is false.
     */
     // "preventManualShrinkwrapChanges": true
  },

  /**
   * Older releases of the Node.js engine may be missing features required by your system.
   * Other releases may have bugs.  In particular, the "latest" version will not be a
   * Long Term Support (LTS) version and is likely to have regressions.
   *
   * Specify a SemVer range to ensure developers use a Node.js version that is appropriate
   * for your repo.
   */
  "nodeSupportedVersionRange": ">=12.17.0 <13.0.0",

  /**
  * Odd-numbered major versions of Node.js are experimental.  Even-numbered releases
  * spend six months in a stabilization period before the first Long Term Support (LTS) version.
  * For example, 8.9.0 was the first LTS version of Node.js 8.  Pre-LTS versions are not recommended
  * for production usage because they frequently have bugs.  They may cause Rush itself
  * to malfunction.
  *
  * Rush normally prints a warning if it detects a pre-LTS Node.js version.  If you are testing
  * pre-LTS versions in preparation for supporting the first LTS version, you can use this setting
  * to disable Rush's warning.
  */
  // "suppressNodeLtsWarning": false,

  /**
   * If you would like the version specifiers for your dependencies to be consistent, then
   * uncomment this line. This is effectively similar to running "rush check" before any
   * of the following commands:
   *
   *   rush install, rush update, rush link, rush version, rush publish
   *
   * In some cases you may want this turned on, but need to allow certain packages to use a different
   * version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"
   * section of the common-versions.json.
   */
    "ensureConsistentVersions": true,

  /**
   * Large monorepos can become intimidating for newcomers if project folder paths don't follow
   * a consistent and recognizable pattern.  When the system allows nested folder trees,
   * we've found that teams will often use subfolders to create islands that isolate
   * their work from others ("shipping the org").  This hinders collaboration and code sharing.
   *
   * The Rush developers recommend a "category folder" model, where buildable project folders
   * must always be exactly two levels below the repo root.  The parent folder acts as the category.
   * This provides a basic facility for grouping related projects (e.g. "apps", "libaries",
   * "tools", "prototypes") while still encouraging teams to organize their projects into
   * a unified taxonomy.  Limiting to 2 levels seems very restrictive at first, but if you have
   * 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds
   * of projects.  In practice, you will find that the folder hierarchy needs to be rebalanced
   * occasionally, but if that's painful, it's a warning sign that your development style may
   * discourage refactoring.  Reorganizing the categories should be an enlightening discussion
   * that brings people together, and maybe also identifies poor coding practices (e.g. file
   * references that reach into other project's folders without using Node.js module resolution).
   *
   * The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.
   *
   * To remove these restrictions, you could set projectFolderMinDepth=1
   * and set projectFolderMaxDepth to a large number.
   */
   "projectFolderMinDepth": 2,
   "projectFolderMaxDepth": 2,

  /**
   * Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early
   * days there was no standard and hardly any enforcement.  A few large legacy projects are still using
   * nonstandard package names, and private registries sometimes allow it.  Set "allowMostlyStandardPackageNames"
   * to true to relax Rush's enforcement of package names.  This allows upper case letters and in the future may
   * relax other rules, however we want to minimize these exceptions.  Many popular tools use certain punctuation
   * characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax
   * the rules too much it is likely to cause very confusing malfunctions.
   *
   * The default value is false.
   */
  // "allowMostlyStandardPackageNames": true,

  /**
   * This feature helps you to review and approve new packages before they are introduced
   * to your monorepo.  For example, you may be concerned about licensing, code quality,
   * performance, or simply accumulating too many libraries with overlapping functionality.
   * The approvals are tracked in two config files "browser-approved-packages.json"
   * and "nonbrowser-approved-packages.json".  See the Rush documentation for details.
   */
  // "approvedPackagesPolicy": {
  //   /**
  //    * The review categories allow you to say for example "This library is approved for usage
  //    * in prototypes, but not in production code."
  //    *
  //    * Each project can be associated with one review category, by assigning the "reviewCategory" field
  //    * in the "projects" section of rush.json.  The approval is then recorded in the files
  //    * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"
  //    * which are automatically generated during "rush update".
  //    *
  //    * Designate categories with whatever granularity is appropriate for your review process,
  //    * or you could just have a single category called "default".
  //    */
  //   "reviewCategories": [
  //     // Some example categories:
  //     "production", // projects that ship to production
  //     "tools",      // non-shipping projects that are part of the developer toolchain
  //     "prototypes"  // experiments that should mostly be ignored by the review process
  //   ],
  //
  //   /**
  //    * A list of NPM package scopes that will be excluded from review.
  //    * We recommend to exclude TypeScript typings (the "@types" scope), because
  //    * if the underlying package was already approved, this would imply that the typings
  //    * are also approved.
  //    */
  //   // "ignoredNpmScopes": [ "@types" ]
  // },

  /**
   * If you use Git as your version control system, this section has some additional
   * optional features you can use.
   */
  "gitPolicy": {
    /**
     * Work at a big company?  Tired of finding Git commits at work with unprofessional Git
     * emails such as "[email protected]"?  Rush can validate people's Git email address
     * before they get started.
     *
     * Define a list of regular expressions describing allowable e-mail patterns for Git commits.
     * They are case-insensitive anchored JavaScript RegExps.  Example: ".*@example\.com"
     *
     * IMPORTANT: Because these are regular expressions encoded as JSON string literals,
     * RegExp escapes need two backspashes, and ordinary periods should be "\\.".
     */
    // "allowedEmailRegExps": [
    //   "[^@]+@users\\.noreply\\.github\\.com",
    //   "travis@example\\.org"
    // ],

    /**
     * When Rush reports that the address is malformed, the notice can include an example
     * of a recommended email.  Make sure it conforms to one of the allowedEmailRegExps
     * expressions.
     */
    // "sampleEmail": "[email protected]",

    /**
     * The commit message to use when committing changes during 'rush publish'.
     *
     * For example, if you want to prevent these commits from triggering a CI build,
     * you might configure your system's trigger to look for a special string such as "[skip-ci]"
     * in the commit message, and then customize Rush's message to contain that string.
     */
    // "versionBumpCommitMessage": "Applying package updates. [skip-ci]"
  },

  "repository": {
    /**
     * The URL of this Git repository, used by "rush change" to determine the base branch for your PR.
     *
     * The "rush change" command needs to determine which files are affected by your PR diff.
     * If you merged or cherry-picked commits from the master branch into your PR branch, those commits
     * should be excluded from this diff (since they belong to some other PR).  In order to do that,
     * Rush needs to know where to find the base branch for your PR.  This information cannot be
     * determined from Git alone, since the "pull request" feature is not a Git concept.  Ideally
     * Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.
     * But to keep things simple, "rush change" simply assumes that your PR is against the "master" branch
     * of the Git remote indicated by the repository.url setting in rush.json.  If you are working in
     * a GitHub "fork" of the real repo, this setting will be different from the repository URL of your
     * your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"
     * to retrieve the latest activity for the remote master branch.
     */
     "url": "git://bitbucket.org/arikon/smart-oil-monorepo.git",

    /**
     * The default branch name. This tells "rush change" which remote branch to compare against.
     * The default value is "master"
     */
    // "defaultBranch": "master",

    /**
     * The default remote. This tells "rush change" which remote to compare against if the remote URL is
     * not set or if a remote matching the provided remote URL is not found.
     */
    // "defaultRemote": "origin"
  },

  /**
   * Event hooks are customized script actions that Rush executes when specific events occur
   */
  "eventHooks": {
    /**
     * The list of shell commands to run before the Rush installation starts
     */
    "preRushInstall": [
      // "common/scripts/pre-rush-install.js"
    ],

    /**
     * The list of shell commands to run after the Rush installation finishes
     */
    "postRushInstall": [],

    /**
     * The list of shell commands to run before the Rush build command starts
     */
    "preRushBuild": [],

    /**
     * The list of shell commands to run after the Rush build command finishes
     */
    "postRushBuild": []
  },

  /**
   * Installation variants allow you to maintain a parallel set of configuration files that can be
   * used to build the entire monorepo with an alternate set of dependencies.  For example, suppose
   * you upgrade all your projects to use a new release of an important framework, but during a transition period
   * you intend to maintain compability with the old release.  In this situation, you probably want your
   * CI validation to build the entire repo twice: once with the old release, and once with the new release.
   *
   * Rush "installation variants" correspond to sets of config files located under this folder:
   *
   *   common/config/rush/variants/<variant_name>
   *
   * The variant folder can contain an alternate common-versions.json file.  Its "preferredVersions" field can be used
   * to select older versions of dependencies (within a loose SemVer range specified in your package.json files).
   * To install a variant, run "rush install --variant <variant_name>".
   *
   * For more details and instructions, see this article:  https://rushjs.io/pages/advanced/installation_variants/
   */
  "variants": [
    // {
    //   /**
    //    * The folder name for this variant.
    //    */
    //   "variantName": "old-sdk",
    //
    //   /**
    //    * An informative description
    //    */
    //   "description": "Build this repo using the previous release of the SDK"
    // }
  ],

  /**
   * Rush can collect anonymous telemetry about everyday developer activity such as
   * success/failure of installs, builds, and other operations.  You can use this to identify
   * problems with your toolchain or Rush itself.  THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.
   * It is written into JSON files in the common/temp folder.  It's up to you to write scripts
   * that read these JSON files and do something with them.  These scripts are typically registered
   * in the "eventHooks" section.
   */
  // "telemetryEnabled": false,

  /**
   * Allows creation of hotfix changes. This feature is experimental so it is disabled by default.
   * If this is set, 'rush change' only allows a 'hotfix' change type to be specified. This change type
   * will be used when publishing subsequent changes from the monorepo.
   */
  // "hotfixChangeEnabled": false,

  /**
   * (Required) This is the inventory of projects to be managed by Rush.
   *
   * Rush does not automatically scan for projects using wildcards, for a few reasons:
   * 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.
   * 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.
   * 3. It's useful to have a centralized inventory of all projects and their important metadata.
   */
  "projects": [
    // {
    //   /**
    //    * The NPM package name of the project (must match package.json)
    //    */
    //   "packageName": "my-app",
    //
    //   /**
    //    * The path to the project folder, relative to the rush.json config file.
    //    */
    //   "projectFolder": "apps/my-app",
    //
    //   /**
    //    * An optional category for usage in the "browser-approved-packages.json"
    //    * and "nonbrowser-approved-packages.json" files.  The value must be one of the
    //    * strings from the "reviewCategories" defined above.
    //    */
    //   "reviewCategory": "production",
    //
    //   /**
    //    * A list of local projects that appear as devDependencies for this project, but cannot be
    //    * locally linked because it would create a cyclic dependency; instead, the last published
    //    * version will be installed in the Common folder.
    //    */
    //   "cyclicDependencyProjects": [
    //     // "my-toolchain"
    //   ],
    //
    //   /**
    //    * If true, then this project will be ignored by the "rush check" command.
    //    * The default value is false.
    //    */
    //   // "skipRushCheck": false,
    //
    //   /**
    //    * A flag indicating that changes to this project will be published to npm, which affects
    //    * the Rush change and publish workflows. The default value is false.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "shouldPublish": false,
    //
    //   /**
    //    * An optional version policy associated with the project.  Version policies are defined
    //    * in "version-policies.json" file.  See the "rush publish" documentation for more info.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "versionPolicyName": ""
    // },

    // packages
    {
      "packageName": "@smart-oil/fueling-data",
      "projectFolder": "packages/fueling-data"
    },
    {
      "packageName": "@smart-oil/ofd-ru-client",
      "projectFolder": "packages/ofd-ru-client"
    },
    {
      "packageName": "@smart-oil/sync-allianz-fueling",
      "projectFolder": "packages/sync-allianz-fueling"
    },
    {
      "packageName": "@smart-oil/sync-ofd-ru-recipes",
      "projectFolder": "packages/sync-ofd-ru-recipes"
    },
    {
      "packageName": "@smart-oil/yandex-cloud-clickhouse",
      "projectFolder": "packages/yandex-cloud-clickhouse"
    },

    // toolchain
    {
      "packageName": "@smart-oil/eslint-config",
      "projectFolder": "toolchain/eslint-config"
    },
    {
      "packageName": "@smart-oil/jest-config",
      "projectFolder": "toolchain/jest-config"
    },
    {
      "packageName": "@smart-oil/jest-environment",
      "projectFolder": "toolchain/jest-environment"
    },
    {
      "packageName": "@smart-oil/prettier-config",
      "projectFolder": "toolchain/prettier-config"
    },
    {
      "packageName": "@smart-oil/tsconfig",
      "projectFolder": "toolchain/tsconfig"
    },
    {
      "packageName": "@smart-oil/yc-function-deploy",
      "projectFolder": "toolchain/yc-function-deploy"
    }
  ]
 }
	/**
	* This configuration file defines a deployment scenario for use with the "rush deploy" command.
	* The scenario files are located under the "common/config/deploy-scenarios" folder.
	* For full documentation, please see https://rushjs.io
	*/
	{
	"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/deploy-scenario.schema.json",

	/**
	* Specify the name of the Rush project to be deployed. The name must be a full package name
	* as declared in rush.json. If you want to include other projects that are not dependencies,
	* add an entry for your main project to the "projectSettings", then use the "additionalProjectsToInclude" setting.
	*
	* The "deploymentProjectNames" array must contain exactly one project, unless "enableSubdeployments" is true;
	* see documentation for that setting for details.
	*/
	"deploymentProjectNames": [
	"@smart-oil/sync-ofd-ru-recipes"
	],

	/**
	* Subdeployments are an optional feature that enables multiple deployments to be prepared by a single
	* invocation of "rush deploy". In this mode, more than one name can be specified for "deploymentProjectNames".
	* For each entry, a subdeployment folder will be created under the "rush deploy" target folder.
	* (The folder name can be customized using the "subdeploymentFolderName" project setting.)
	* Each subdeployment folder will receive its own copy of the named project and its associated dependencies.
	*
	* The default value is false.
	*/
	"enableSubdeployments": false,

	/**
	* When deploying a local Rush project, by the "devDependencies" are normally excluded.
	* Set this to "true" to include them.
	*
	* The default value is false.
	*/
	// "includeDevDependencies": true,

	/**
	* When deploying a local Rush project, normally the .npmignore filter is applied so that Rush only copies
	* files that would be packaged by "npm pack". Setting "includeNpmIgnoreFiles" to true will disable this
	* filtering so that all files are copied (with a few trivial exceptions such as the "node_modules" folder).
	*
	* The default value is false.
	*/
	// "includeNpmIgnoreFiles": true,

	/**
	* Specify how symlinks will be created in the deployed folder:
	*
	* - "default": Create the symlinks after copying the files; this is the default behavior.
	* - "script": A Node.js script called "create-symlinks.js" will be written. When executed, this script will
	* create the symlinks described in the "deploy-metadata.json" output file.
	* - "none": Do nothing; some other tool may create them later.
	*/
	// "symlinkCreation": "script",

	/**
	* Customize how Rush projects are processed during deployment.
	*/
	"projectSettings": [
	// {
	// /**
	// * The full package name of the project, which must be declared in rush.json.
	// */
	// "projectName": "@my-scope/my-project",
	//
	// /**
	// * This optional setting is only relevant when "enableSubdeployments" is true. It customizes the
	// * subdeployment folder name. If omitted, the default subdeployment folder name will be the
	// * package name without its NPM scope.
	// */
	// // "subdeploymentFolderName": "my-proj",
	//
	// /**
	// * A list of additional local Rush projects to be deployed with this project (beyond the package.json
	// * dependencies). Specify full package names, which must be declared in rush.json.
	// */
	// "additionalProjectsToInclude": [
	// // "@my-scope/my-project2"
	// ]
	// }
	]
	}
	/**
	* This is the main configuration file for Rush.
	* For full documentation, please see https://rushjs.io
	*/
	{
	"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

	/**
	* (Required) This specifies the version of the Rush engine to be used in this repo.
	* Rush's "version selector" feature ensures that the globally installed tool will
	* behave like this release, regardless of which version is installed globally.
	*
	* The common/scripts/install-run-rush.js automation script also uses this version.
	*
	* NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"
	* path segment in the "$schema" field for all your Rush config files. This will ensure
	* correct error-underlining and tab-completion for editors such as VS Code.
	*/
	"rushVersion": "5.23.6-pr1898.0",

	/**
	* The next field selects which package manager should be installed and determines its version.
	* Rush installs its own local copy of the package manager to ensure that your build process
	* is fully isolated from whatever tools are present in the local environment.
	*
	* Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion". See the Rush documentation
	* for details about these alternatives.
	*/
	"pnpmVersion": "5.0.2",

	// "npmVersion": "4.5.0",
	// "yarnVersion": "1.9.4",

	/**
	* Options that are only used when the PNPM package manager is selected
	*/
	"pnpmOptions": {
	/**
	* Specifies the location of the PNPM store. There are two possible values:
	*
	* - "local" - use the "pnpm-store" folder in the current configured temp folder:
	* "common/temp/pnpm-store" by default.
	* - "global" - use PNPM's global store, which has the benefit of being shared
	* across multiple repo folders, but the disadvantage of less isolation for builds
	* (e.g. bugs or incompatibilities when two repos use different releases of PNPM)
	*
	* RUSH_PNPM_STORE_PATH will override the directory that will be used as the store
	*
	* In all cases, the store path will be overridden by the environment variable RUSH_PNPM_STORE_PATH.
	*
	* The default value is "local".
	*/
	"pnpmStore": "local",

	/**
	* If true, then Rush will add the "--strict-peer-dependencies" option when invoking PNPM.
	* This causes "rush install" to fail if there are unsatisfied peer dependencies, which is
	* an invalid state that can cause build failures or incompatible dependency versions.
	* (For historical reasons, JavaScript package managers generally do not treat this invalid
	* state as an error.)
	*
	* The default value is false to avoid legacy compatibility issues.
	* It is strongly recommended to set strictPeerDependencies=true.
	*/
	// "strictPeerDependencies": true,


	/**
	* Configures the strategy used to select versions during installation.
	*
	* This feature requires PNPM version 3.1 or newer. It corresponds to the "--resolution-strategy" command-line
	* option for PNPM. Possible values are "fast" and "fewer-dependencies". PNPM's default is "fast", but this may
	* be incompatible with certain packages, for example the "@types" packages from DefinitelyTyped. Rush's default
	* is "fewer-dependencies", which causes PNPM to avoid installing a newer version if an already installed version
	* can be reused; this is more similar to NPM's algorithm.
	*
	* After modifying this field, it's recommended to run "rush update --full" so that the package manager
	* will recalculate all version selections.
	*/
	// "resolutionStrategy": "fast",

	/**
	* If true, then `rush install` will report an error if manual modifications
	* were made to the PNPM shrinkwrap file without running "rush update" afterwards.
	*
	* This feature protects against accidental inconsistencies that may be introduced
	* if the PNPM shrinkwrap file ("pnpm-lock.yaml") is manually edited. When this
	* feature is enabled, "rush update" will append a hash to the file as a YAML comment,
	* and then "rush update" and "rush install" will validate the hash. Note that this does not prohibit
	* manual modifications, but merely requires "rush update" be run
	* afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
	*
	* To temporarily disable this validation when invoking "rush install", use the
	* "--bypass-policy" command-line parameter.
	*
	* The default value is false.
	*/
	// "preventManualShrinkwrapChanges": true
	},

	/**
	* Older releases of the Node.js engine may be missing features required by your system.
	* Other releases may have bugs. In particular, the "latest" version will not be a
	* Long Term Support (LTS) version and is likely to have regressions.
	*
	* Specify a SemVer range to ensure developers use a Node.js version that is appropriate
	* for your repo.
	*/
	"nodeSupportedVersionRange": ">=12.17.0 <13.0.0",

	/**
	* Odd-numbered major versions of Node.js are experimental. Even-numbered releases
	* spend six months in a stabilization period before the first Long Term Support (LTS) version.
	* For example, 8.9.0 was the first LTS version of Node.js 8. Pre-LTS versions are not recommended
	* for production usage because they frequently have bugs. They may cause Rush itself
	* to malfunction.
	*
	* Rush normally prints a warning if it detects a pre-LTS Node.js version. If you are testing
	* pre-LTS versions in preparation for supporting the first LTS version, you can use this setting
	* to disable Rush's warning.
	*/
	// "suppressNodeLtsWarning": false,

	/**
	* If you would like the version specifiers for your dependencies to be consistent, then
	* uncomment this line. This is effectively similar to running "rush check" before any
	* of the following commands:
	*
	* rush install, rush update, rush link, rush version, rush publish
	*
	* In some cases you may want this turned on, but need to allow certain packages to use a different
	* version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"
	* section of the common-versions.json.
	*/
	"ensureConsistentVersions": true,

	/**
	* Large monorepos can become intimidating for newcomers if project folder paths don't follow
	* a consistent and recognizable pattern. When the system allows nested folder trees,
	* we've found that teams will often use subfolders to create islands that isolate
	* their work from others ("shipping the org"). This hinders collaboration and code sharing.
	*
	* The Rush developers recommend a "category folder" model, where buildable project folders
	* must always be exactly two levels below the repo root. The parent folder acts as the category.
	* This provides a basic facility for grouping related projects (e.g. "apps", "libaries",
	* "tools", "prototypes") while still encouraging teams to organize their projects into
	* a unified taxonomy. Limiting to 2 levels seems very restrictive at first, but if you have
	* 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds
	* of projects. In practice, you will find that the folder hierarchy needs to be rebalanced
	* occasionally, but if that's painful, it's a warning sign that your development style may
	* discourage refactoring. Reorganizing the categories should be an enlightening discussion
	* that brings people together, and maybe also identifies poor coding practices (e.g. file
	* references that reach into other project's folders without using Node.js module resolution).
	*
	* The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.
	*
	* To remove these restrictions, you could set projectFolderMinDepth=1
	* and set projectFolderMaxDepth to a large number.
	*/
	"projectFolderMinDepth": 2,
	"projectFolderMaxDepth": 2,

	/**
	* Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early
	* days there was no standard and hardly any enforcement. A few large legacy projects are still using
	* nonstandard package names, and private registries sometimes allow it. Set "allowMostlyStandardPackageNames"
	* to true to relax Rush's enforcement of package names. This allows upper case letters and in the future may
	* relax other rules, however we want to minimize these exceptions. Many popular tools use certain punctuation
	* characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax
	* the rules too much it is likely to cause very confusing malfunctions.
	*
	* The default value is false.
	*/
	// "allowMostlyStandardPackageNames": true,

	/**
	* This feature helps you to review and approve new packages before they are introduced
	* to your monorepo. For example, you may be concerned about licensing, code quality,
	* performance, or simply accumulating too many libraries with overlapping functionality.
	* The approvals are tracked in two config files "browser-approved-packages.json"
	* and "nonbrowser-approved-packages.json". See the Rush documentation for details.
	*/
	// "approvedPackagesPolicy": {
	// /**
	// * The review categories allow you to say for example "This library is approved for usage
	// * in prototypes, but not in production code."
	// *
	// * Each project can be associated with one review category, by assigning the "reviewCategory" field
	// * in the "projects" section of rush.json. The approval is then recorded in the files
	// * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"
	// * which are automatically generated during "rush update".
	// *
	// * Designate categories with whatever granularity is appropriate for your review process,
	// * or you could just have a single category called "default".
	// */
	// "reviewCategories": [
	// // Some example categories:
	// "production", // projects that ship to production
	// "tools", // non-shipping projects that are part of the developer toolchain
	// "prototypes" // experiments that should mostly be ignored by the review process
	// ],
	//
	// /**
	// * A list of NPM package scopes that will be excluded from review.
	// * We recommend to exclude TypeScript typings (the "@types" scope), because
	// * if the underlying package was already approved, this would imply that the typings
	// * are also approved.
	// */
	// // "ignoredNpmScopes": [ "@types" ]
	// },

	/**
	* If you use Git as your version control system, this section has some additional
	* optional features you can use.
	*/
	"gitPolicy": {
	/**
	* Work at a big company? Tired of finding Git commits at work with unprofessional Git
	* emails such as "[email protected]"? Rush can validate people's Git email address
	* before they get started.
	*
	* Define a list of regular expressions describing allowable e-mail patterns for Git commits.
	* They are case-insensitive anchored JavaScript RegExps. Example: ".*@example\.com"
	*
	* IMPORTANT: Because these are regular expressions encoded as JSON string literals,
	* RegExp escapes need two backspashes, and ordinary periods should be "\\.".
	*/
	// "allowedEmailRegExps": [
	// "[^@]+@users\\.noreply\\.github\\.com",
	// "travis@example\\.org"
	// ],

	/**
	* When Rush reports that the address is malformed, the notice can include an example
	* of a recommended email. Make sure it conforms to one of the allowedEmailRegExps
	* expressions.
	*/
	// "sampleEmail": "[email protected]",

	/**
	* The commit message to use when committing changes during 'rush publish'.
	*
	* For example, if you want to prevent these commits from triggering a CI build,
	* you might configure your system's trigger to look for a special string such as "[skip-ci]"
	* in the commit message, and then customize Rush's message to contain that string.
	*/
	// "versionBumpCommitMessage": "Applying package updates. [skip-ci]"
	},

	"repository": {
	/**
	* The URL of this Git repository, used by "rush change" to determine the base branch for your PR.
	*
	* The "rush change" command needs to determine which files are affected by your PR diff.
	* If you merged or cherry-picked commits from the master branch into your PR branch, those commits
	* should be excluded from this diff (since they belong to some other PR). In order to do that,
	* Rush needs to know where to find the base branch for your PR. This information cannot be
	* determined from Git alone, since the "pull request" feature is not a Git concept. Ideally
	* Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.
	* But to keep things simple, "rush change" simply assumes that your PR is against the "master" branch
	* of the Git remote indicated by the repository.url setting in rush.json. If you are working in
	* a GitHub "fork" of the real repo, this setting will be different from the repository URL of your
	* your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"
	* to retrieve the latest activity for the remote master branch.
	*/
	"url": "git://bitbucket.org/arikon/smart-oil-monorepo.git",

	/**
	* The default branch name. This tells "rush change" which remote branch to compare against.
	* The default value is "master"
	*/
	// "defaultBranch": "master",

	/**
	* The default remote. This tells "rush change" which remote to compare against if the remote URL is
	* not set or if a remote matching the provided remote URL is not found.
	*/
	// "defaultRemote": "origin"
	},

	/**
	* Event hooks are customized script actions that Rush executes when specific events occur
	*/
	"eventHooks": {
	/**
	* The list of shell commands to run before the Rush installation starts
	*/
	"preRushInstall": [
	// "common/scripts/pre-rush-install.js"
	],

	/**
	* The list of shell commands to run after the Rush installation finishes
	*/
	"postRushInstall": [],

	/**
	* The list of shell commands to run before the Rush build command starts
	*/
	"preRushBuild": [],

	/**
	* The list of shell commands to run after the Rush build command finishes
	*/
	"postRushBuild": []
	},

	/**
	* Installation variants allow you to maintain a parallel set of configuration files that can be
	* used to build the entire monorepo with an alternate set of dependencies. For example, suppose
	* you upgrade all your projects to use a new release of an important framework, but during a transition period
	* you intend to maintain compability with the old release. In this situation, you probably want your
	* CI validation to build the entire repo twice: once with the old release, and once with the new release.
	*
	* Rush "installation variants" correspond to sets of config files located under this folder:
	*
	* common/config/rush/variants/<variant_name>
	*
	* The variant folder can contain an alternate common-versions.json file. Its "preferredVersions" field can be used
	* to select older versions of dependencies (within a loose SemVer range specified in your package.json files).
	* To install a variant, run "rush install --variant <variant_name>".
	*
	* For more details and instructions, see this article: https://rushjs.io/pages/advanced/installation_variants/
	*/
	"variants": [
	// {
	// /**
	// * The folder name for this variant.
	// */
	// "variantName": "old-sdk",
	//
	// /**
	// * An informative description
	// */
	// "description": "Build this repo using the previous release of the SDK"
	// }
	],

	/**
	* Rush can collect anonymous telemetry about everyday developer activity such as
	* success/failure of installs, builds, and other operations. You can use this to identify
	* problems with your toolchain or Rush itself. THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.
	* It is written into JSON files in the common/temp folder. It's up to you to write scripts
	* that read these JSON files and do something with them. These scripts are typically registered
	* in the "eventHooks" section.
	*/
	// "telemetryEnabled": false,

	/**
	* Allows creation of hotfix changes. This feature is experimental so it is disabled by default.
	* If this is set, 'rush change' only allows a 'hotfix' change type to be specified. This change type
	* will be used when publishing subsequent changes from the monorepo.
	*/
	// "hotfixChangeEnabled": false,

	/**
	* (Required) This is the inventory of projects to be managed by Rush.
	*
	* Rush does not automatically scan for projects using wildcards, for a few reasons:
	* 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.
	* 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.
	* 3. It's useful to have a centralized inventory of all projects and their important metadata.
	*/
	"projects": [
	// {
	// /**
	// * The NPM package name of the project (must match package.json)
	// */
	// "packageName": "my-app",
	//
	// /**
	// * The path to the project folder, relative to the rush.json config file.
	// */
	// "projectFolder": "apps/my-app",
	//
	// /**
	// * An optional category for usage in the "browser-approved-packages.json"
	// * and "nonbrowser-approved-packages.json" files. The value must be one of the
	// * strings from the "reviewCategories" defined above.
	// */
	// "reviewCategory": "production",
	//
	// /**
	// * A list of local projects that appear as devDependencies for this project, but cannot be
	// * locally linked because it would create a cyclic dependency; instead, the last published
	// * version will be installed in the Common folder.
	// */
	// "cyclicDependencyProjects": [
	// // "my-toolchain"
	// ],
	//
	// /**
	// * If true, then this project will be ignored by the "rush check" command.
	// * The default value is false.
	// */
	// // "skipRushCheck": false,
	//
	// /**
	// * A flag indicating that changes to this project will be published to npm, which affects
	// * the Rush change and publish workflows. The default value is false.
	// * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
	// */
	// // "shouldPublish": false,
	//
	// /**
	// * An optional version policy associated with the project. Version policies are defined
	// * in "version-policies.json" file. See the "rush publish" documentation for more info.
	// * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
	// */
	// // "versionPolicyName": ""
	// },

	// packages
	{
	"packageName": "@smart-oil/fueling-data",
	"projectFolder": "packages/fueling-data"
	},
	{
	"packageName": "@smart-oil/ofd-ru-client",
	"projectFolder": "packages/ofd-ru-client"
	},
	{
	"packageName": "@smart-oil/sync-allianz-fueling",
	"projectFolder": "packages/sync-allianz-fueling"
	},
	{
	"packageName": "@smart-oil/sync-ofd-ru-recipes",
	"projectFolder": "packages/sync-ofd-ru-recipes"
	},
	{
	"packageName": "@smart-oil/yandex-cloud-clickhouse",
	"projectFolder": "packages/yandex-cloud-clickhouse"
	},

	// toolchain
	{
	"packageName": "@smart-oil/eslint-config",
	"projectFolder": "toolchain/eslint-config"
	},
	{
	"packageName": "@smart-oil/jest-config",
	"projectFolder": "toolchain/jest-config"
	},
	{
	"packageName": "@smart-oil/jest-environment",
	"projectFolder": "toolchain/jest-environment"
	},
	{
	"packageName": "@smart-oil/prettier-config",
	"projectFolder": "toolchain/prettier-config"
	},
	{
	"packageName": "@smart-oil/tsconfig",
	"projectFolder": "toolchain/tsconfig"
	},
	{
	"packageName": "@smart-oil/yc-function-deploy",
	"projectFolder": "toolchain/yc-function-deploy"
	}
	]
	}