Download the PHP package jasonterando/config-validator without Composer
On this page you can find all versions of the php package jasonterando/config-validator. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download jasonterando/config-validator
More information about jasonterando/config-validator
Files in jasonterando/config-validator
Package config-validator
Short Description Utility to collect and validate configuration information
License MIT
Homepage https://github.com/jasonterando/configuration-validator/
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package config-validator
Configuration Validator
Overview
This is an Autoload implemented utility that provides a mechanism to ensure that deployed configuration files meet the requirements of any dependencies. It is meant to be executed in development or at the time of deployment.
An application and/or its dependencies each define a configuration definition file. When the Configuration Validation utility is executed, the utility compares the Application Configuration versus and Configuration Definitions inlcuded in dependencies.
Currently, Configuration Definition files are located using directories included Autoload PSR-4 and Classmap directories. Application Configuration files are retrieved using Zend's module manager convention (module_listener_options/module_paths). It's envisioned that additional mechanisms to retrieve Configuration Definitions and Application Configurations will be added in the future.
Installation and Usage
Installation
To use this:
- Run
- Add the composer script lines to composer.json
`
Usage
From the application's main directory, run to run the validation. If everything checks out, a success message will be displayed and the exit code will be zero.
If the validation fails, due to missing or invalid configuration entries, warnings will be displayed and the exit code will be -2.
If the validation cannot run due to a fatal error, the exception message will be displayed and the exit code will be -1.
If you need to create a configuration validation file from scratch, you can run which will create a definition file, based upon the application's current configuration, that you can refine and include with your module/library. Note that this file will include all application configuration, so you will want to remove entries that aren't required by your specific module, and likely set some types, before moving the file to your module's folder.
Both of the Composer scripts shown above can be run with the argument to provide more information about what files are being accessed.
CI/CD Integration
During deployment, after installing/updating configuration files, run to validate the configuration. Any exit code other than zero should be treated as a failure and stop the deployment.
Configuration Definitions
Configuration Definition File Format
Configuration Definition files are in YAML format. They can be named or , and located in any directory defined as a PSR-4 or Classmap path in an Autoload project's composer.json. For example:
`
Every leaf in the tree corresponds to a Configuration Item, located with the hiearchy of its parent nodes. Configuration Items have two properties, type and required. By default, Configuration Items can be of any type, and are required.
In the example above, the final Configuration Item, "copyright" can be any value, but must exist in the Application Configuration. The "timeout" property is not requiredto exist in the Application Configuration file, but must be an integer (whole number) if it is.
There are two entries, "logo" and "logs" which must be an existing file and directory, respectively. Note that this check is done withing the user context that the test is run, which may not be the same as the context the application itself runs in, so this isn't a 100% foolproof check.
For "service1", its endpoint Configuration Item is required and must be a valid URL. The "key" and "secret" Configuration Items are required to be defined (under "credentials") and be non-empty strings.
For this example, a working configuration file may look something like this: `
Configuration Definition Item Types
The following types are currently supported:
- any: can be any value, including empty
- string: can be anything that PHP can render as a string, but not empty
- number: any numeric value
- integer: any whole value (positive or negative) but without a decimal portion
- boolean: any boolean-ish value (true/value, y/n, yes/no)
- url: any well-structured URL
- directory: an existing, accessible directory
- file: an existing, accessible file
Development
Unit Testing
Unit tests, including code coverage, can be executed by running from the library's main folder.
Todo's
- Add support for PSR-0
- Add support for other frameworks' Application Configuration file stores (Symphony?)
- Add more aggressive location and/or configuration settings (somewhere) for things like Autoload and Application Configuration files
