zlatko-ms / envarfiles Goto Github PK

Add support for properties defined in a YAML file.

The feature should support :

• identifying yaml files depending on the file extension ( .yml , .yaml )
• yaml syntax validation prior to parsing
• nested keys

Nested Keys

All keys , including nested ones, should be considered as variable names.

For instance :

release:
  version:
    major: 1.0
    minor: 4

should provide the following list of variables to inject :

release.version.major=1.0
release.version.minor=4

YAML Syntax validation

The easiest way of doing this is to exec a simple yq -e , if the return code is 0 then it is a valid yaml format

Notes

If the json parsing is implemented, then the yaml part can be branched on json by converting the yaml file to json using yq :

yq -j file.yaml

Add support for properties defined in a json file.

The feature should support :

• identifying json files depending on the file extension ( .json )
• json syntax validation prior to parsing
• nested keys

Nested Keys

All keys , including nested ones, should be considered as variable names.

For instance :

{ "version" : { "major" : "1.0" , "minor" : "4" } }

should provide the following list of variables to inject :

version.major=1.0
version.minor=4

JSON Syntax validation

The easiest way of doing this is to exec a simple jr -r , if the return code is 0 then it is a valid json format

Usage links are not correct, only the selection illustration had the correct pointer

Currently the default behaviour is to override existing variable values from file.

Should be changed to :

• default : no override
• when override=true : override the values

• remove all the action logic implemented in shell
• shell for testing vars in the IT can be conserved for now

Refactor integration test for better coverage and clarity.

Features to test :

• import variables from files without override
• import variables from files with override
• import variables only from valid files, ignore others
• import variables from files with comments

Formats on which to test all the features :

• Plain Text
• JSON
• YAML
• Combined file set containing Plain, JSON and YAML

I am trying to run this action from a private repository but I get this message:
Unable to resolve action. Repository not found: zlatko-ms/varfiletoenv
When running the action from a public repository everything works perfectly

Could you provide me any help to solve this problem?. Thanks in advance

Currently the ITs use actions under the previous name, fix this ASAP !!!!

Build is a pre-requisite for test jobs.

Internal logs might be useful when looking for a specific definition issue, however they are not necessary in all cases and can become a burden when looking at large workflow logs.

An input parameter should indicate whenever to produce the internal logs.

Provide a way to read the variables from more then a single file.

A possible usage would be the following :

    - name: Import project variables
      uses: zlatko-ms/varfiletoenv@v1
      with:
        files:
          ./test/projectvars.properties
          ./conf/myvars.config

• improve workflow rebase tool
• add internal logs
• use items when iterating over dict
• examine slicing build process
• examine uploading coverage report

Shell is nice to start with, but we are not in 1978 any more and the listed enhancements will require more processing logic and therefore tests.

Hence we need to move the implementation to a higher level language in order to provide a sustainable maintenance process and also internal unit tests.

We suggest to move the implementation to python3 and to hold additional enhancement requests until this refactoring is completed.

add support of hcl (2) format to help IaC projects

Add an input paramter to support a selection of variables by their name.

The rationale is to avoid to import a bunch of variables from a (large) file , if you simply need a couple of them.

Possible usage definition :

    - name: Import project variables with overriding
      uses: zlatko-ms/varfiletoenv@v1
      with:
        names: |
             version
             rtag
        paths: ./src/main/resources/tags.txt

would only import the variables version and rtag from the tags.txt file.

Add support of a flag to control the overriding of variables from the file.

When the flag is set to true ( default value ), then the file definitions would override any variable within the workflow with same name.

When flag is set to false, then the override would be disabled and variables defined in the workflow files would not be overriden.

A possible usage would be :

    - name: Import project variables
      uses: zlatko-ms/varfiletoenv@v1
      with:
         override: false
         files:
          ./test/projectvars.properties
          ./conf/myvars.config

Define a single Known Issues section in the doc, eventually link it from other sections.

Re-organize the ITs in order to provide :

• integration tests per supported format ( plain, json, yaml .... )
• integration tests per features : override, logs, separator ....

reduce overall IT execution time

• split requiremnts.txt into two files : one for the action runtime, the other for python build
• update workflows and docker file

Remove scripted coverage check and replace it with pycovcheck GH action

Currently the nested properties are separated via a fixed, underscore symbol.

Implement a parameter to override this character and support some of the Java/JS use cases on properties files