Cleanup changes, revert style modifications made by pre-commit

This commit is contained in:
Natalia
2023-05-08 15:28:04 -03:00
parent 1aecc94521
commit 76e2c75dcf
28 changed files with 100 additions and 99 deletions

View File

@@ -1,26 +1,26 @@
# Management Commands
# Management Commands
## `create_sample_data`
Running this command will populate the database with fake data for local development.
When run, it will create fake objects for these models:
When run, it will create fake objects for these models:
- User
- User
- Version
- Category
- Category
- Library
- LibraryVersion
- Authors for Libraries and Maintainers for LibraryVersions
- Issues and Pull Requests for Libraries
- Authors for Libraries and Maintainers for LibraryVersions
- Issues and Pull Requests for Libraries
The data generated is fake. Any links, information that looks like it comes from GitHub, email addresses, etc. is all fake. Some of it is made to look like realistic data.
The data generated is fake. Any links, information that looks like it comes from GitHub, email addresses, etc. is all fake. Some of it is made to look like realistic data.
The following options can be used with the command:
- `--all`: If True, run all methods including the drop command.
If you don't want to drop all records for the above models and create a new set of fresh data, you can pass these options to clear your database or and create new records.
If you don't want to drop all records for the above models and create a new set of fresh data, you can pass these options to clear your database or and create new records.
- `--drop`: If True, drop all records in the database.
- `--users`: If True, create fake users.
@@ -37,7 +37,7 @@ If you don't want to drop all records for the above models and create a new set
./manage.py create_sample_data --all
Output:
Output:
Dropping all records...
Dropping Non-Superusers...
@@ -68,11 +68,11 @@ Output:
...10 issues created for algorithm
### Example: Create new pull requests and issues for existing library objects
### Example: Create new pull requests and issues for existing library objects
./manage.py create_sample_data --prs --issues
./manage.py create_sample_data --prs --issues
Output:
Output:
Adding library pull requests...
...9 pull requests created for algorithm
@@ -82,15 +82,15 @@ Output:
...10 issues created for asio
## `generate_fake_versions`
## `generate_fake_versions`
Creates fake Version objects **only**, then creates LibraryVersion objects for each existing Library and the new Versions.
Creates fake Version objects **only**, then creates LibraryVersion objects for each existing Library and the new Versions.
### Example:
### Example:
./manage.py generate_fake_versions
Output:
Output:
Version 1.30.0 created succcessfully
---algorithm (1.30.0) created succcessfully
@@ -98,14 +98,14 @@ Output:
## `update_libraries`
Runs the library update script, which cycles through the repos listed in the Boost library and syncs their information.
Runs the library update script, which cycles through the repos listed in the Boost library and syncs their information.
Synced information:
Synced information:
- Most library information comes from `meta/libraries.json` stored in each Boost library repo
- Library data and metadata from GitHub is saved to our database
- Categories are updated, if needed
- Library categories are updated, if need be.
- Issues and Pull Requests are synced
- Most library information comes from `meta/libraries.json` stored in each Boost library repo
- Library data and metadata from GitHub is saved to our database
- Categories are updated, if needed
- Library categories are updated, if need be.
- Issues and Pull Requests are synced
**NOTE**: Can take upwards of a half hour to run. If you are trying to populate tables for local development, `create_sample_data` is a better option if the GitHub integrations aren't important.
**NOTE**: Can take upwards of a half hour to run. If you are trying to populate tables for local development, `create_sample_data` is a better option if the GitHub integrations aren't important.

View File

@@ -1,37 +1,37 @@
# Environment Variables
This project uses environment variables to configure certain aspects of the application.
This project uses environment variables to configure certain aspects of the application.
## `GITHUB_TOKEN`
- Used to authenticate with the GitHub API when making requests.
- For **local development**, you should set this variable to a valid personal access token that has the necessary permissions to access the relevant repositories. [Generate a new personal access token](https://github.com/settings/tokens) and replace the value for `GITHUB_TOKEN` in your `.env` file in order to connect to certain parts of the GitHub API.
- In **deployed environments**, this should be set to a valid access token associated with the GitHub organization. Edit `kube/boost/values.yaml` (or the environment-specific yaml file) to change this value.
- Used to authenticate with the GitHub API when making requests.
- For **local development**, you should set this variable to a valid personal access token that has the necessary permissions to access the relevant repositories. [Generate a new personal access token](https://github.com/settings/tokens) and replace the value for `GITHUB_TOKEN` in your `.env` file in order to connect to certain parts of the GitHub API.
- In **deployed environments**, this should be set to a valid access token associated with the GitHub organization. Edit `kube/boost/values.yaml` (or the environment-specific yaml file) to change this value.
## `ENVIRONMENT_NAME`
- Used to indicate the name of the environment where the application is running.
- For **local development**, set this to whatever you want.
- In **deployed environments**, change the value by editing `kube/boost/values.yaml` (or the environment-specific yaml file).
- Used to indicate the name of the environment where the application is running.
- For **local development**, set this to whatever you want.
- In **deployed environments**, change the value by editing `kube/boost/values.yaml` (or the environment-specific yaml file).
## `STATIC_CONTENT_AWS_ACCESS_KEY_ID`
- Used to authenticate with the Amazon Web Services (AWS) API when accessing static content from a specified bucket.
- For **local development**, obtain valid value from the Boost team.
- Used to authenticate with the Amazon Web Services (AWS) API when accessing static content from a specified bucket.
- For **local development**, obtain valid value from the Boost team.
- In **deployed environments**, the valid value is set as a kube secret and is defined in `kube/boost/values.yaml` (or the environment-specific yaml file).
## `STATIC_CONTENT_AWS_SECRET_ACCESS_KEY`
- Used to authenticate with the Amazon Web Services (AWS) API when accessing static content from a specified bucket.
- For **local development**, obtain valid value from the Boost team.
- Used to authenticate with the Amazon Web Services (AWS) API when accessing static content from a specified bucket.
- For **local development**, obtain valid value from the Boost team.
- In **deployed environments**, the valid value is set as a kube secret and is defined in `kube/boost/values.yaml` (or the environment-specific yaml file).
## `STATIC_CONTENT_BUCKET_NAME`
- Specifies the name of the Amazon S3 bucket where static content is stored
- For **local development**, obtain valid value from the Boost team.
- For **local development**, obtain valid value from the Boost team.
- In **deployed environments**, the valid value is set in `kube/boost/values.yaml` (or the environment-specific yaml file).

View File

@@ -1,6 +1,6 @@
# Retrieving Static Content from the Boost Amazon S3 Bucket
# Retrieving Static Content from the Boost Amazon S3 Bucket
The `StaticContentTemplateView` class (in the `core/` app) is a Django view that handles requests for static content.
The `StaticContentTemplateView` class (in the `core/` app) is a Django view that handles requests for static content.
Its URL path is the very last path in our list of URL patterns (see `config/urls.py`) because it functions as the fallback URL pattern. If a user enters a URL that doesn't match anything else defined in our URL patterns, this view will attempt to retrieve the request as static content from S3 using the URL path.
@@ -8,7 +8,7 @@ The `StaticContentTemplateView` calls S3 using the URL pattern and generates a l
Boost uses the AWS SDK for Python (boto3) to connect to an S3 bucket and retrieve the static content. If no bucket name is provided, pur process uses the `STATIC_CONTENT_BUCKET_NAME` setting from the Django project settings.
## How we decide which S3 keys to try
## How we decide which S3 keys to try
The JSON config file `{env}_static_config.json` is used to map site paths to corresponding paths in the Amazon S3 bucket where static content is stored. This mapping is used to create shortcuts to static content files in the S3 bucket, which can be accessed using URLs that correspond to the site paths.
@@ -20,7 +20,7 @@ The `s3_path` property is the path to the static content file in the S3 bucket.
When a request is made to a URL that corresponds to a site path, the get_content_from_s3() function looks up the site path in the `{env}_static_config.json` file to find the corresponding S3 path. It then uses the S3 path to retrieve the static content from the S3 bucket.
Take a look at this sample `{env}_static_config.json` file:
Take a look at this sample `{env}_static_config.json` file:
```javascript
[
@@ -42,15 +42,15 @@ Take a look at this sample `{env}_static_config.json` file:
**Example 1**: If the URL request is for `/develop/libs/index.html`, the S3 keys that we would try are:
- `/site/develop/libs/index.html`
**Example 2**: If the URL request is for `/develop/doc/index.html`, the S3 keys that the function would try are:
- `/site/develop/doc/html/index.html`
- `/site/develop/doc/index.html`
**Example 3**: If the URL request is for `/index.html`, the S3 keys that the function would try are:
- `/site/develop/index.html`
- `/site/index.html`
We first try to retrieve the static content using the exact S3 key specified in the site-to-S3 mapping. If we can't find the content using that key, we will try alternative S3 keys based on the `site_path` and `s3_path` properties in the `{env}_static_config.json` file.
We first try to retrieve the static content using the exact S3 key specified in the site-to-S3 mapping. If we can't find the content using that key, we will try alternative S3 keys based on the `site_path` and `s3_path` properties in the `{env}_static_config.json` file.