Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring/13 documentation and formatting #30

Merged
merged 29 commits into from
Sep 2, 2024
Merged
Show file tree
Hide file tree
Changes from 9 commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
8e1b161
Implementing suggested bug fixes to the POC.
MobiTikula Aug 2, 2024
0a0498d
Updating README.md with new section `Expected Output`.
MobiTikula Aug 8, 2024
96a1a5a
Removing Todos from the project. Improving action input logic.
MobiTikula Aug 8, 2024
f06dc31
action.yml and README.md files updated for current state of POC.
MobiTikula Aug 9, 2024
be75de8
Constants handling improved to have all project constants on one plac…
MobiTikula Aug 9, 2024
f6802f3
First phase of pylint refactoring.
MobiTikula Aug 12, 2024
d678e81
Second phase of linting the project.
MobiTikula Aug 12, 2024
0677c53
Third phase of linting the project.
MobiTikula Aug 12, 2024
7c0f8c1
Last phase of linting the project.
MobiTikula Aug 12, 2024
b3e3d99
Code format checked with BLACK: The Uncompromising Code Formatter.
MobiTikula Aug 13, 2024
eb6b679
Adding the class docstrings documentation to the project.
MobiTikula Aug 14, 2024
e465f58
Adding the module docstrings documentation to the project.
MobiTikula Aug 14, 2024
a22f30e
Method docstring documentation added to the project.
MobiTikula Aug 14, 2024
c39b54b
Solving merge conflicts.
MobiTikula Aug 28, 2024
0b29d27
Docstrings update for liv-generator-model.
MobiTikula Aug 28, 2024
7708806
Docstrings update for liv-generator-utils.
MobiTikula Aug 28, 2024
d5e2d21
Docstrings update based on the new standards.
MobiTikula Aug 28, 2024
b9e4d68
Formating project with black tool.
MobiTikula Aug 29, 2024
5db1778
Review comments implemented into POC.
MobiTikula Aug 29, 2024
0bdbf9b
Updated README.md for using a Black formatting tool.
MobiTikula Aug 30, 2024
c807e2c
Updated README.md for using a Black formatting tool.
MobiTikula Aug 30, 2024
9c49482
Updated README.md for using tools.
MobiTikula Aug 30, 2024
b70f0e9
Comments suggestions added.
MobiTikula Sep 2, 2024
56d941e
Black workflow added.
MobiTikula Sep 2, 2024
a9def3f
CI black wrong commit.
MobiTikula Sep 2, 2024
830ccc6
CI black workflow implemented.
MobiTikula Sep 2, 2024
3cdfef6
Update static_analysis_and_tests.yml
MobiTikula Sep 2, 2024
fdafc07
Bug fixes.
MobiTikula Sep 2, 2024
1324bc6
Merge remote-tracking branch 'origin/refactoring/13-Documentation-and…
MobiTikula Sep 2, 2024
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions .pylintrc
Original file line number Diff line number Diff line change
Expand Up @@ -179,7 +179,7 @@ const-naming-style=UPPER_CASE

# Minimum line length for functions/classes that require docstrings, shorter
# ones are exempt.
docstring-min-length=-1
docstring-min-length=5

# Naming style matching correct function names.
function-naming-style=snake_case
Expand Down Expand Up @@ -426,11 +426,7 @@ confidence=HIGH,
# --enable=similarities". If you want to run only the classes checker, but have
# no Warning level messages displayed, use "--disable=all --enable=classes
# --disable=W".
# TODO: Remove after this PR
disable=C0116,
C0115,
C0114,
raw-checker-failed,
disable=raw-checker-failed,
bad-inline-option,
locally-disabled,
file-ignored,
Expand Down
96 changes: 73 additions & 23 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
- [Project Setup](#project-setup)
- [Run Scripts Locally](#run-scripts-locally)
- [Run Pylint Check Locally](#run-pylint-check-locally)
- [Run Black Tool Locally](#run-black-tool-locally)
- [Run unit test](#run-unit-test)
- [Deployment](#deployment)
- [Features](#features)
Expand Down Expand Up @@ -76,12 +77,6 @@ See the full example of action step definition (in example are used non-default
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
# project state mining de/activation
project-state-mining: true

# project verbose (debug) logging de/activation
verbose-logging: true

# input repositories + feature to filter projects
repositories: '[
{
Expand Down Expand Up @@ -156,7 +151,7 @@ Configure the action by customizing the following parameters based on your needs
]'
```

### Features de/activation
### Features De/Activation
- **project-state-mining** (optional, `default: false`)
- **Description**: Enables or disables the mining of project state data from [GitHub Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects).
- **Usage**: Set to true to activate.
Expand Down Expand Up @@ -193,23 +188,29 @@ The Living Documentation Generator action provides a key output that allows user
## Expected Output
The Living Documentation Generator is designed to produce an Issue Summary page (index.md) along with multiple detailed single issue pages.

### Index page example
### Index Page Example

```markdown
# Issue Summary page

Our project is designed with a myriad of issues to ensure seamless user experience, top-tier functionality, and efficient operations.
Here, you'll find a summarized list of all these issues, their brief descriptions, and links to their detailed documentation.

## Issue Overview
| Organization name| Repository name | Issue 'Number - Title' | Linked to project | Project Status | Issue URL |
|------------------|----------------------------|-----------------------------------------------|-------------------|----------------|------------|
|AbsaOSS | living-doc-example-project | [#89 - Test issue 2](89_test_issue_2.md) | 🔴 | --- |[GitHub](#) |
|AbsaOSS | living-doc-example-project | [#88 - Test issue](88_test_issue.md) | 🟢 | Todo |[GitHub](#) |
|AbsaOSS | living-doc-example-project | [#41 - Initial commit.](41_initial_commit.md) | 🟢 | Done |[GitHub](#) |
|AbsaOSS | living-doc-example-project | [#33 - Example bugfix](33_example_bugfix.md) | 🔴 | --- |[GitHub](#) |

| Organization name| Repository name | Issue 'Number - Title' | Linked to project | Project Status | Issue URL |
|------------------|----------------------------|--------------------------------|-------------------|----------------|------------|
| AbsaOSS | living-doc-example-project | [#89 - Test issue 2](89_test_issue_2.md) | 🔴 | --- |[GitHub](#) |
| AbsaOSS | living-doc-example-project | [#88 - Test issue](88_test_issue.md) | 🟢 | Todo |[GitHub](#) |
| AbsaOSS | living-doc-example-project | [#41 - Initial commit.](41_initial_commit.md) | 🟢 | Done |[GitHub](#) |
| AbsaOSS | living-doc-example-project | [#33 - Example bugfix](33_example_bugfix.md) | 🔴 | --- |[GitHub](#) |
```

### Issue page example
- **Project Status** can have various values depending on the project, such as: Todo, Done, Closed, In Progress, In Review, Blocked, etc.
These values can vary from project to project.
- The `---` symbol is used to indicate that an issue has no required project data.

### Issue Page Example

```markdown
# FEAT: Advanced Book Search
Expand Down Expand Up @@ -255,7 +256,7 @@ pip install -r requirements.txt
## Run Scripts Locally
If you need to run the scripts locally, follow these steps:

### Create the shell script
### Create the Shell Script
Create the shell file in the root directory. We will use `run_script.sh`.
```shell
touch run_script.sh
Expand All @@ -265,13 +266,11 @@ Add the shebang line at the top of the sh script file.
#!/bin/sh
```

### Set the environment variables
### Set the Environment Variables
Set the configuration environment variables in the shell script following the structure below.
Also make sure that the GITHUB_TOKEN is configured in your environment variables.
```
export INPUT_GITHUB_TOKEN=$(printenv GITHUB_TOKEN)
export INPUT_PROJECT_STATE_MINING="true"
export INPUT_VERBOSE_LOGGING="true"
export INPUT_REPOSITORIES='[
{
"organization-name": "Organization Name",
Expand Down Expand Up @@ -340,20 +339,71 @@ Example:
pylint living_documentation_generator/generator.py
```

## Run unit test
### Expected Output
This is the console expected output example after running the tool:
```
************* Module main
main.py:30:0: C0116: Missing function or method docstring (missing-function-docstring)

------------------------------------------------------------------
Your code has been rated at 9.41/10 (previous run: 8.82/10, +0.59)
```

## Run Black Tool Locally
This project uses the Black tool for code formatting.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This project uses the Black tool for code formatting.
This project uses the [Black](https://github.com/psf/black) tool for code formatting.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change as well as for Pylint tool: fdafc07

Black aims for consistency, generality, readability and reducing git diffs.
The coding style used can be viewed as a strict subset of PEP 8.

The project root file `pyproject.toml` defines the Black tool configuration.
In this project we are accepting the line length of 120 characters.

Follow these steps to format your code with Black locally:

### Set Up Python Environment
From terminal in the root of the project, run the following command:

```shell
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
```

This command will also install a Black tool, since it is listed in the project requirements.

### Run Black
Run Black on all files that are currently tracked by Git in the project.
```shell
black $(git ls-files '*.py')
```

To run Black on a specific file, follow the pattern `black <path_to_file>/<name_of_file>.py`.

Example:
```shell
black living_documentation_generator/generator.py
```

### Expected Output
This is the console expected output example after running the tool:
```
All done! ✨ 🍰 ✨
1 file reformatted.
```

## Run Unit Test
TODO - check this chapter and update by latest state
### Launch unit tests
### Launch Unit Tests
```
pytest
```

### To run specific tests or get verbose output:
### To Run Specific Tests or Get Verbose Output:
```
pytest -v # Verbose mode
pytest path/to/test_file.py # Run specific test file
```

### To check Test Coverage:
### To Check Test Coverage:
```
pytest --cov=../scripts
```
Expand Down
31 changes: 11 additions & 20 deletions living_documentation_generator/action_inputs.py
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,16 @@
#

"""
This module contains the ActionInputs class which is responsible for loading, managing and validating the inputs
required for running the GH Action.
This module contains an Action Inputs class methods,
which are essential for running the GH action.
"""

import json
import logging
import sys

from living_documentation_generator.model.config_repository import ConfigRepository
from living_documentation_generator.utils.utils import (
get_action_input,
make_absolute_path,
)
from living_documentation_generator.utils.utils import get_action_input, make_absolute_path
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From how many import items are required ()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever line is more than 120 char. The rules are still same. BUT If we talking about for example constants, which can increase during the time, I also think is alright to put them under each other. Black way of formatting is to reduce as many extra lines as possible. But it won't change your code, if you choose to put just two of your imports under each other.

from living_documentation_generator.utils.constants import (
GITHUB_TOKEN,
PROJECT_STATE_MINING,
Expand All @@ -40,14 +37,10 @@

class ActionInputs:
"""
A class representing all inputs that are essential for running the GH action.

Attributes:
__github_token (str): The GitHub token used for authentication.
__is_project_state_mining_enabled (bool): Switch indicating if project state mining is enabled.
__repositories (list[ConfigRepository]): List of config repositories to fetch from.
__output_directory (str): The directory where the markdown pages will be stored.
A class representing all the action inputs. It is responsible for loading, managing
and validating the inputs required for running the GH Action.
"""

def __init__(self):
self.__github_token: str = ""
self.__is_project_state_mining_enabled: bool = False
Expand Down Expand Up @@ -78,13 +71,11 @@ def load_from_environment(self, validate: bool = True) -> "ActionInputs":
"""
Load the action inputs from the environment variables and validate them if needed.

Args:
validate (bool): Switch indicating if the inputs should be validated.
@param validate: Switch indicating if the inputs should be validated.
@return: The instance of the ActionInputs class.
"""
self.__github_token = get_action_input(GITHUB_TOKEN)
self.__is_project_state_mining_enabled = (
get_action_input(PROJECT_STATE_MINING, "false").lower() == "true"
)
self.__is_project_state_mining_enabled = get_action_input(PROJECT_STATE_MINING, "false").lower() == "true"
out_path = get_action_input(OUTPUT_PATH, "./output")
self.__output_directory = make_absolute_path(out_path)
repositories_json = get_action_input(REPOSITORIES, "")
Expand Down Expand Up @@ -115,8 +106,8 @@ def validate_inputs(self, repositories_json: str) -> None:
"""
Validate the input attributes of the action.

Args:
repositories_json(str): The JSON string containing the repositories to fetch.
@param repositories_json: The JSON string containing the repositories to fetch.
@return: None
"""

# Validate correct format of input repositories_json
Expand Down
Loading