Skip to content
Snippets Groups Projects
Commit 79f91069 authored by mjbonifa's avatar mjbonifa
Browse files

docs:added hatch documentation, resulted in fix to project toml to run the dev tools #7

parent c82cfa17
No related branches found
No related tags found
No related merge requests found
...@@ -205,25 +205,37 @@ This will create a virtual environment with all required dependencies. ...@@ -205,25 +205,37 @@ This will create a virtual environment with all required dependencies.
## Development Environment ## Development Environment
### Activate the Development Environment By defining two separate environments, we ensure that development dependencies (such as testing tools, linters, or other utilities) don't interfere with your production environment. The default environment is the bare minimum required to run the application, while the dev environment includes everything need for development.
- default environment: Includes the core dependencies your app needs to run (e.g., requests, etc.).
- dev environment: Includes additional tools for testing, code formatting, linting, and other development workflows (e.g., pytest, black, mypy, etc.).
### Activate Default Environment
To enter the development environment, use: To enter the development environment, use:
```sh ```sh
hatch shell hatch shell
``` ```
### Activate the Development Environment
To enter the development environment, use:
```sh
hatch shell dev
```
### Code Formatting ### Code Formatting
The project uses `black` for code formatting. Ensure your code is properly formatted before committing: The project uses `black` for code formatting. Ensure your code is properly formatted before committing:
```sh ```sh
black acmc hatch run black --check acmc
``` ```
### Type Checking ### Type Checking
The project uses `mypy` for type checking: The project uses `mypy` for type checking:
```sh ```sh
mypy acmc hatch run mypy -p acmc
``` ```
### Running Tests ### Running Tests
...@@ -248,33 +260,29 @@ acmc --help ...@@ -248,33 +260,29 @@ acmc --help
``` ```
## Contributing ## Contributing
If you make changes, ensure all tests pass and code formatting is correct before submitting a merge request.
1. Create a new branch for your feature or bugfix: ### GitLab Basic Workflow
1. Create an new issue in the [Issue Tracker](https://git.soton.ac.uk/meldb/concepts-processing/-/issues)
2. Create a new branch for your feature or bugfix:
```sh ```sh
git checkout -b feature-branch git checkout -b feature-branch
``` ```
2. Make changes and commit them: 3. Make changes and commit them:
```sh ```sh
git add . git add .
git commit -m "Description of changes" git commit -m "Description of changes"
``` ```
3. Push your branch: 4. Push your branch:
```sh ```sh
git push origin feature-branch git push origin feature-branch
``` ```
4. Open a merge request in GitLab. 5. Open a merge request in GitLab.
## Additional Resources
- [Repository](https://git.soton.ac.uk/meldb/concepts-processing)
- [Documentation](https://git.soton.ac.uk/meldb/concepts-processing/docs)
- [Issue Tracker](https://git.soton.ac.uk/meldb/concepts-processing/-/issues)
If you make changes, ensure all tests pass and code formatting is correct before submitting a merge request.
# GitLab Workflow for Managing Releases ## GitLab Workflow for Managing Releases
## Branching Strategy
### 1. Main Branch (`main`) ### 1. Main Branch (`main`)
- Represents the stable production-ready code. - Represents the stable production-ready code.
...@@ -320,14 +328,18 @@ If you make changes, ensure all tests pass and code formatting is correct before ...@@ -320,14 +328,18 @@ If you make changes, ensure all tests pass and code formatting is correct before
- Deploy to production after approval. - Deploy to production after approval.
- Requires authorization from a repository maintainer or admin before merging. - Requires authorization from a repository maintainer or admin before merging.
## Commit Message Guidelines ### Commit Message Guidelines
- Use clear and descriptive commit messages. - Use clear and descriptive commit messages.
- Format: `<type>(<scope>): <description>` - Format: `<type>(<scope>): <description>`
- Example: `docs (documentation): git workflow documentation (#issue)` - Example: `docs: git workflow documentation (#issue)`
- Types: `feat` (feature), `fix` (bug fix), `docs` (documentation), `refactor` (code refactoring), `test` (tests), `chore` (maintenance). - Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`.
## Additional Guidelines ## Additional Guidelines
- Always pull the latest changes before starting a new feature: `git pull origin dev` - Always pull the latest changes before starting a new feature: `git pull origin dev`
- Write unit tests for new features. - Write unit tests for new features.
- Keep feature branches short-lived and regularly updated with `dev`. - Keep feature branches short-lived and regularly updated with `dev`.
## Additional Resources
- [Repository](https://git.soton.ac.uk/meldb/concepts-processing)
- [Documentation](https://git.soton.ac.uk/meldb/concepts-processing/docs)
- [Issue Tracker](https://git.soton.ac.uk/meldb/concepts-processing/-/issues)
\ No newline at end of file
...@@ -53,7 +53,7 @@ packages = ["acmc"] ...@@ -53,7 +53,7 @@ packages = ["acmc"]
[tool.hatch.envs.default] [tool.hatch.envs.default]
dependencies = [ dependencies = [
"hatch", "hatch",
"pytest" "pytest",
] ]
[tool.hatch.envs.dev] [tool.hatch.envs.dev]
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment