Merge pull request #533 from elixir-luxembourg/develop

v1.8.2

.env.template

@@ -0,0 +1,7 @@
+# Database configuration
+DB_NAME=daisy
+DB_USER=daisy
+DB_PASSWORD=daisy
+
+# Backup configuration
+BACKUP_VOLUME=../backups

.github/workflows/main.yml

@@ -25,17 +25,17 @@ jobs:
       run: cp elixir_daisy/settings_compose_ci.py elixir_daisy/settings_compose.py
 
     - name: Build and start containers
-      run: docker-compose up -d --build
+      run: docker compose up -d --build
 
     - name: Check code formatting with Black
-      run: docker-compose exec -T web black --check --verbose .
+      run: docker compose exec -T web black --check --verbose .
 
     - name: Install test dependencies
-      run: docker-compose exec -T web pip install ".[test]"
+      run: docker compose exec -T web pip install ".[test]"
 
     - name: Execute the tests
-      run: docker-compose exec -T web pytest
+      run: docker compose exec -T web pytest
 
     - name: Stop containers
       if: always()
-      run: docker-compose down
+      run: docker compose down

.github/workflows/release.yml

@@ -0,0 +1,27 @@
+name: Validate Version bump upon release
+
+on:
+  release:
+    types: [created]
+
+jobs:
+  validate-version:
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v2
+
+    - name: Set up Python
+      uses: actions/setup-python@v2
+      with:
+        python-version: '3.x'
+
+    - name: Validate version in setup.py
+      run: |
+        VERSION=$(python setup.py --version)
+        echo "Version in setup.py: $VERSION"
+        if [[ "v$VERSION" != "$GITHUB_REF_NAME" ]]; then
+          echo "Version mismatch: setup.py (v$VERSION) vs release tag ($GITHUB_REF_NAME)"
+          exit 1
+        fi

CONTRIBUTING.md

@@ -0,0 +1,46 @@
+# Contribution
+
+This guide outlines the process for contributing to this repository.
+
+## GitHub Workflow
+
+We follow a standard GitHub workflow for contributions:
+
+1. Fork the repository [if needed]
+2. Create a new branch
+3. Make your changes
+4. Submit a pull request
+
+## Pull Requests
+
+- All major contributions should be made through pull requests (PRs).
+- Branch names should start with the issue number (e.g., `124-fancy-new-feature`).
+- PRs can be opened as soon as the branch is created. Use draft PRs for work in progress.
+- PR titles should include the issue number (e.g., "#98: Improve error handling").
+- Include relevant implementation notes and any deviations from the original issue description in the PR description.
+- If the changes impact the user interface, include screenshots in the PR description.
+- Resolve any merge conflicts before requesting a review.
+
+## Definition of "Done" (DoD)
+
+Before marking a PR as ready for review, ensure:
+
+- All issue requirements are implemented
+- CI pipeline is passing
+- Test coverage is maintained or improved
+- Unit tests cover the new implementation (except for very minor changes)
+- Documentation (including README) is updated if necessary
+- New methods and classes have docstrings and type hints
+
+## Code Review Process
+
+- At least one approval from another team member is required before merging.
+- Reviewers should check out the branch and test the feature, not just review the code.
+- Use GitHub's review features for inline comments and general feedback.
+- The PR author should address all comments and request re-review when ready.
+- Reviewers should resolve comment threads once satisfied with the changes.
+- After all threads are resolved and the PR is approved, it can be merged.
+
+## After Merging
+
+- Close the related issue once the PR is merged and the implementation has been verified in the test environment.