# bulk-approve-graph

Made to run on scheduler.theorchard.io, this script will accept either a table of `ORCH_RELEASE_ID` values (Orchard release_id's) or a single release_id value,  validate the release for approval, and mark the release as `in_content`.

It can be run locally for various use cases.

## Scheduler Job (LIVE):
https://scheduler.theorchard.io/job/bulk-approve-graph/

## ELI5
1. Get Release ID's
1. Loop through ID's
    1. Validate a release ID (ensure no missing assets, metadata, etc.) 
    1. Approve the release ID
    1. Log success/fail to console.
    1. Loop

## .env Variables
```
# Envirnoment
ENVIRONMENT=DEV  # QA/Prod on scheduler

# GraphQL
GRAPHQL_GATEWAY_URL=  # The URL of the graph instance to which to send queries
OA_USER=  # Must be a user with proper permissions. Recommend using OA service-user.

# Snowflake 
# These must be provided by Devops for deploy, or use your own creds for local ad-hoc)
SNOWFLAKE_ACCOUNT=orchard
SNOWFLAKE_USER=
SNOWFLAKE_ROLE=DEV_ENGINEERING
SNOWFLAKE_DATABASE=
SNOWFLAKE_SCHEMA=
SNOWFLAKE_KEY_PASSPHRASE=

# Application Vars
# The table which contains the release_id values (see note "Release ID" below)
SNOWFLAKE_SOURCE_TABLE=

# For single release testing / approval - If present, this overrides the table var above. 
# Do either SNOWFLAKE_SOURCE_TABLE or RELEASE_ID, not both.
#RELEASE_ID=
```

## Snowflake Table notes
### Release ID
The `release_id` field name to be retrieved from the source table is defined in the file `constants/fields.py`. Ours is `orch_release_id`. Yours may be different.

### SNOWFLAKE_KEY_PASSPHRASE
To facilitate local snowflake testing, the config file will look for the `SNOWFLAKE_PRIVATE_KEY_PATH` and the `SNOWFLAKE_KEY_PASSPHRASE` values in the envirnment, and use those for Snowflake access (both when running locally or on `scheduler.theorchard.io`)

Please inspect the section `Snowflake PEM-key RSA auth` in `config.py` for implementation. It attempts to failsafe to expected locations for Unix-like and Windows systems.

## Logging and Datadog
This script was extracted from a larger project which makes use of `loguru` for pretty-printed and threaded logging. 

This script requires a LOGGER_DSN value to ship the logs to Datadog via `fluentd`.

An example query for datadog would be as follows:

https://app.datadoghq.com/logs?query=%40service%3A%2Abulk-approve%2A%20%40environment%3Aqa%20%40correlation_id%3Afe758ea0-332e-40e4-8e0e-1b09bafe741e&cols=service_name%2C%40correlation_id%2Cenv%2C%40service&event=AQAAAYPIQWM5PrVf5gAAAABBWVBJUVlZd0FBQ29ST2EtaW5wc3ZnQVk&index=&messageDisplay=inline&stream_sort=time%2Cdesc&viz=stream&from_ts=1662922315722&to_ts=1665514315722&live=true

The `@service` filter is your friend (`@service_name` will always be `fluentd`)