diff --git a/episodes/02-Copy-Template.md b/episodes/02-Copy-Template.md index cb422ad491a235c632edc08a9d3aa26c4ae2ba75..548fe125543a33856ab030e64d3bdc7a4957bbc4 100755 --- a/episodes/02-Copy-Template.md +++ b/episodes/02-Copy-Template.md @@ -120,10 +120,10 @@ The template comes with a basic test suite using `pytest`. Navigate to the `nova ::::::::::::::: solution - * **Where are the tests located?** The tests are typically located in the `tests/` directory, often mirroring the structure of the `src/` directory (e.g., `tests/nova_tutorial/test_module.py`). - * **What does a successful test look like?** A successful test will usually result in output from `pytest` that indicates all tests have passed (e.g., "100% passed"). There will be no error messages. The exact output varies slightly depending on the number of tests and the pytest configuration. - * **Modify the test to intentionally fail:** To make a test fail, you can change an assertion to be incorrect. For example, if a test asserts that `1 + 1 == 2`, change it to `1 + 1 == 3`. - * **Observe the error message:** The error message will indicate which assertion failed and provide information about the expected and actual values. For example, you might see something like: `AssertionError: assert 2 == 3`. +* **Where are the tests located?** The tests are typically located in the `tests/` directory, often mirroring the structure of the `src/` directory (e.g., `tests/nova_tutorial/test_module.py`). +* **What does a successful test look like?** A successful test will usually result in output from `pytest` that indicates all tests have passed (e.g., "100% passed"). There will be no error messages. The exact output varies slightly depending on the number of tests and the pytest configuration. +* **Modify the test to intentionally fail:** To make a test fail, you can change an assertion to be incorrect. For example, if a test asserts that `1 + 1 == 2`, change it to `1 + 1 == 3`. +* **Observe the error message:** The error message will indicate which assertion failed and provide information about the expected and actual values. For example, you might see something like: `AssertionError: assert 2 == 3`. ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -132,18 +132,18 @@ The template comes with a basic test suite using `pytest`. Navigate to the `nova ## **Explore Pre-Commit Hooks** The template includes pre-commit hooks for code formatting and linting. - * **Inspect the Configuration:** Open the `.pre-commit-config.yaml` file. What tools are configured to run? What does each tool do (e.g., `black`, `flake8`)? - * **Try It Out:** Make a deliberate formatting error in one of the Python files (e.g., add extra spaces, make a line too long). Now, run `pre-commit run`. Observe how the pre-commit hooks automatically fix the formatting issues. Commit your changes. Pre-commit hooks can also be automatically run upon git commit. -::::::::::::::: solution +* **Inspect the Configuration:** Open the `.pre-commit-config.yaml` file. What tools are configured to run? What does each tool do (e.g., `black`, `flake8`)? +* **Try It Out:** Make a deliberate formatting error in one of the Python files (e.g., add extra spaces, make a line too long). Now, run `pre-commit run`. Observe how the pre-commit hooks automatically fix the formatting issues. Commit your changes. Pre-commit hooks can also be automatically run upon git commit. - * **What tools are configured to run?** Open `.pre-commit-config.yaml` to see the list. Common tools include: - * `black`: Auto-formats Python code to adhere to a consistent style. - * `flake8`: Lints Python code, checking for style errors and potential bugs. - * `isort`: Sorts Python imports alphabetically and separates them into sections. - * `end-of-file-fixer`: Ensures that files end with a newline. - * `trailing-whitespace-fixer`: Removes trailing whitespace from lines. - * **Observe how the pre-commit hooks automatically fix the formatting issues:** When you run `pre-commit run`, the configured tools will automatically modify the files to correct formatting errors. The output will show which tools were run and which files were modified. You\'ll need to `git add` the modified files before committing. +::::::::::::::: solution +* **What tools are configured to run?** Open `.pre-commit-config.yaml` to see the list. Common tools include: + * `black`: Auto-formats Python code to adhere to a consistent style. + * `flake8`: Lints Python code, checking for style errors and potential bugs. + * `isort`: Sorts Python imports alphabetically and separates them into sections. + * `end-of-file-fixer`: Ensures that files end with a newline. + * `trailing-whitespace-fixer`: Removes trailing whitespace from lines. +* **Observe how the pre-commit hooks automatically fix the formatting issues:** When you run `pre-commit run`, the configured tools will automatically modify the files to correct formatting errors. The output will show which tools were run and which files were modified. You\'ll need to `git add` the modified files before committing. ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -153,19 +153,20 @@ The template includes pre-commit hooks for code formatting and linting. ## **CI/CD Setup with GitLab CI** The template includes a basic GitLab CI configuration file (`.gitlab-ci.yml`). While we won\'t fully execute a CI/CD pipeline in this tutorial step, let\'s understand its purpose. - * **Examine the Configuration:** Open the `.gitlab-ci.yml` file. This file defines the *pipeline*. What are the key stages defined in the pipeline (e.g., build, test, deploy)? Identify the jobs that install dependencies, run tests, and perform linting. What triggers the pipeline to run (e.g., pushes, merge requests)? - * **GitLab Runner:** GitLab CI/CD uses *runners* to execute the jobs defined in your `.gitlab-ci.yml` file. These runners can be configured in various ways. (No action required; this is just an informational point.) - * **Discussion:** If you were to push this project to a GitLab repository, what would happen when you create a merge request? How could you use CI/CD to automatically verify the code quality of your project? (No action required; this is a thought exercise.) + +* **Examine the Configuration:** Open the `.gitlab-ci.yml` file. This file defines the *pipeline*. What are the key stages defined in the pipeline (e.g., build, test, deploy)? Identify the jobs that install dependencies, run tests, and perform linting. What triggers the pipeline to run (e.g., pushes, merge requests)? +* **GitLab Runner:** GitLab CI/CD uses *runners* to execute the jobs defined in your `.gitlab-ci.yml` file. These runners can be configured in various ways. (No action required; this is just an informational point.) +* **Discussion:** If you were to push this project to a GitLab repository, what would happen when you create a merge request? How could you use CI/CD to automatically verify the code quality of your project? (No action required; this is a thought exercise.) ::::::::::::::: solution - * **What are the key stages defined in the pipeline?** The stages typically include: - * `build`: Installs dependencies and prepares the application for testing. - * `test`: Runs the unit tests. - * `lint`: Performs code linting and formatting checks. - * `deploy` (optional): Deploys the application to a server or environment. - * **Identify the jobs that install dependencies, run tests, and perform linting:** Look for job definitions that use commands like `pip install`, `pytest`, and `flake8` (or similar linting tools). - * **What triggers the pipeline to run?** The pipeline is typically triggered by pushes to the repository and the creation of merge requests. This is defined in the `.gitlab-ci.yml` file using keywords like `on: [push, merge_requests]`. - * **If you were to push this project to a GitLab repository, what would happen when you create a merge request?** A pipeline would be automatically triggered. The pipeline would run the jobs defined in `.gitlab-ci.yml`, such as installing dependencies, running tests, and performing linting. The results of the pipeline would be displayed in the merge request, allowing you to see if the code passes all checks before merging it. This helps ensure code quality and prevents broken code from being merged into the main branch. +* **What are the key stages defined in the pipeline?** The stages typically include: + * `build`: Installs dependencies and prepares the application for testing. + * `test`: Runs the unit tests. + * `lint`: Performs code linting and formatting checks. + * `deploy` (optional): Deploys the application to a server or environment. +* **Identify the jobs that install dependencies, run tests, and perform linting:** Look for job definitions that use commands like `pip install`, `pytest`, and `flake8` (or similar linting tools). +* **What triggers the pipeline to run?** The pipeline is typically triggered by pushes to the repository and the creation of merge requests. This is defined in the `.gitlab-ci.yml` file using keywords like `on: [push, merge_requests]`. +* **If you were to push this project to a GitLab repository, what would happen when you create a merge request?** A pipeline would be automatically triggered. The pipeline would run the jobs defined in `.gitlab-ci.yml`, such as installing dependencies, running tests, and performing linting. The results of the pipeline would be displayed in the merge request, allowing you to see if the code passes all checks before merging it. This helps ensure code quality and prevents broken code from being merged into the main branch. ::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::::::::::::