Adding parameters for recipe and GDK config custom file selection and new Push command for local deployment

[iakko]

Issue #, if available:

N/A

Description of changes:

Adding the following capabilities:

• Adding new optional parameters to the component build command:

  • [-c GDK_CONFIG]: to specify a custom gdk-config.json file.
  • [-r RECIPE]: to specify a custom recipe.json file.
  • [-u BUILD_DIR]: to specify a custom greengrass-build folder for built artifact/recipe.

• Adding new optional parameters to the component publish command:

  • [-c GDK_CONFIG]: to specify a custom gdk-config.json file.
  • [-u BUILD_DIR]: to specify a custom greengrass-build folder for built artifact/recipe. Note that the recipe file will be searched into the BUILD_DIR and not in the working directory. It will also respect the COMPONENT_NAME and COMPONENT_VERSION format in case they are provided (see below), or the default recipe.{json,yaml} if not.
  • [-n COMPONENT_NAME]: to specify a custom component name to be used to create the built version of the recipe file. This is useful in case the BUILD_DIR contains an artifact produced by the component push command (see below for details on this new command).
  • [-w COMPONENT_VERSION]: to specify a custom component version to be used to create the built version of the recipe file. This is useful in case the BUILD_DIR contains an artifact produced by the component push command (see below for details on this new command).

Adding a new component push command for local deployment of the final artifact. This command is useful in case you want to avoid deploying the component through the standard process which requires to pass through the cloud even for local testing. The target folder will contain the artifact with proper artifacts folder's structure and the renamed recipe file with <component_name>-<component_version>.<extention>. This command will also respect the "NEXT_PATCH" directive in the gdk-config file, checking the destination folder structure, calculating the proper next version according to existing version folders (as it does right now with the component publish command).

The command will have the following parameters:

• [-h]: for help
• [-d]: for debugging messages:
• [-v]: version (global parameter)
• [-c GDK_CONFIG]: to specify a custom gdk-config.json file.
• [-u BUILD_DIR]: to specify a custom greengrass-build folder for built artifact/recipe to be pushed.
• -e DESTINATION: the target destination of the component location. The format of this parameter must start with file://<local_destination_path> because the idea is to be able to use an S3 bucket in case we want to centralize component in a remote location using s3://<bucket_name>/<bucket_folder>. This last option is not implemented yet.

Why is this change necessary:

This will enable local testing in case of a local Greengrass instance.

How was this change tested:

Using the standard commands as per current implementation (1.1.0), everything will work as usual (allowing retrofitting). In case you want to test the new local location, you can do the following:

0. Place the prompt to the component root folder (assuming that we are using the standard recipe.json and gdk.config.json project files, but you can change them with proper options).
1. Build the component as usual: gdk component build -d -c gdk-config.json -r recipe.json -u greengrass-build
2. Push the component locally: gdk component push -u greengrass-build -e file:///tmp/gg
3. Check content of /tmp/gg: tree /tmp/gg (should contain the standard component structure with artifacts and recipes folders. The recipes one should contain the <component_name>-<component_version>.<extention> file and the artifcats directory should contain the <version> properly calculated folder(or 1.0.0 if new) with the artifact inside.
4. Publish component on cloud retrieving the built artifact from local folder: gdk component publish -d -c gdk-config.json -u /tmp/gg -n <component_name> -w <component_version>.

Any additional information or context required to review the change:

Checklist:

• Updated the README if applicable
• [N/A] Updated or added new unit tests
• [N/A] Updated or added new integration tests
• [N/A] Updated or added new end-to-end tests
• If your code makes a remote network call, it was tested with a proxy
• You confirm that the change is backwards compatible

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.