Rename project_name to project_id

.github/workflows/python-ci.yml

@@ -44,9 +44,6 @@ jobs:
       - name: Check pyproject.toml file
         run: poetry check
 
-      - name: Install tox
-        run: pip install tox
-
       - name: Authenticate with Google Cloud
         id: auth
         uses: google-github-actions/[email protected]
@@ -56,11 +53,14 @@ jobs:
           workload_identity_provider: "projects/437801218871/locations/global/workloadIdentityPools/github-actions-pool/providers/github-actions-provider"
           service_account: "[email protected]"
 
+      - name: Install package
+        run: poetry install --all-extras -v
+
       - name: Run tests
-        env:
-          TEST_PROJECT_NAME: ${{ secrets.TEST_PROJECT_NAME }}
-          GOOGLE_CLOUD_PROJECT: ${{ secrets.TEST_PROJECT_NAME }}
-        run: tox -vv -e py
+        run: |
+          poetry run coverage run --source octue -m unittest discover
+          poetry run coverage report --show-missing
+          poetry run coverage xml
 
       - name: Upload coverage to Codecov
         uses: codecov/codecov-action@v4

.github/workflows/release.yml

@@ -48,9 +48,6 @@ jobs:
       - name: Check pyproject.toml file
         run: poetry check
 
-      - name: Install tox
-        run: pip install tox
-
       - name: Authenticate with Google Cloud
         id: auth
         uses: google-github-actions/[email protected]
@@ -60,11 +57,14 @@ jobs:
           workload_identity_provider: "projects/437801218871/locations/global/workloadIdentityPools/github-actions-pool/providers/github-actions-provider"
           service_account: "[email protected]"
 
+      - name: Install package
+        run: poetry install --all-extras -v
+
       - name: Run tests
-        env:
-          TEST_PROJECT_NAME: ${{ secrets.TEST_PROJECT_NAME }}
-          GOOGLE_CLOUD_PROJECT: ${{ secrets.TEST_PROJECT_NAME }}
-        run: tox -vv -e py
+        run: |
+          poetry run coverage run --source octue -m unittest discover
+          poetry run coverage report --show-missing
+          poetry run coverage xml
 
       - name: Upload coverage to Codecov
         uses: codecov/codecov-action@v4

README.md

@@ -86,20 +86,13 @@ Then run the tests to check everything's working.
 These environment variables need to be set to run the tests:
 
 - `GOOGLE_APPLICATION_CREDENTIALS=/absolute/path/to/service/account/file.json`
-- `TEST_PROJECT_NAME=<name-of-google-cloud-project-to-run-pub-sub-tests-on>`
 
 Then, from the repository root, run
 
 ```shell
 python3 -m unittest
 ```
 
-or
-
-```shell
-tox
-```
-
 ## Contributing
 
 Take a look at our [contributing](/docs/contributing.md) page.

docs/contributing.md

@@ -1,21 +1,23 @@
 # Contributing
 
 ## Developing the SDK
+
 - We follow a test-driven development (TDD) approach and require a high test coverage of each PR.
 - We use [`pre-commit`](https://pre-commit.com/) to apply consistent code quality checks and linting to new code, commit messages, and documentation - see [below](#pre-commit) for how to set this up
 - Documentation is automatically built by `pre-commit` but needs to be updated with any changes to public interface of the package
 
-
 ## Releases
+
 We use continuous deployment and semantic versioning for our releases:
+
 - Continuous deployment - each pull request into `main` constitutes a new version
 - [Semantic versioning](https://semver.org/) supported by [Conventional Commits](https://github.com/octue/conventional-commits) - to automate meaningful version numbering
 - Conventional Commit messages - these are essential for the above to be automated. We've developed a `pre-commit` check that guides and enforces this.
 
-
 ## Pull requests
 
 ### Internal developers
+
 1. Check out a new branch
 2. Create a pull request into the `main` branch
 3. Undertake your changes, committing and pushing to your branch
@@ -27,11 +29,13 @@ We use continuous deployment and semantic versioning for our releases:
 9. Merge into `main`. A release will automatically be created on GitHub and published to PyPi and Docker Hub.
 
 ### External developers
+
 - Please [raise an issue](https://github.com/octue/octue-sdk-python/issues) (or add your $0.02 to an existing issue) so
   the maintainers know what's happening and can advise/steer you.
 
 - Create a fork of `octue-sdk-python`, undertaking your changes on a new branch, (see `.pre-commit-config.yaml` for
   branch naming conventions). To run tests and make commits, you'll need to do something like:
+
   ```
   git clone <your_forked_repo_address>                          # Fetches the repo to your local machine
   cd octue-sdk-python                                           # Move into the repo directory
@@ -40,17 +44,18 @@ We use continuous deployment and semantic versioning for our releases:
   pip install poetry                                            # Installs the poetry package manager
   poetry install --all-extras                                   # Installs the package editably, including developer dependencies (e.g. testing and code formatting utilities)
   pre-commit install && pre-commit install -t commit-msg        # Installs the pre-commit hooks in the git repo
-  tox                                                           # Runs the tests
+  poetry run python3 -m unittest                                # Runs the tests
   ```
 
 - Open a pull request into the `main` branch of `octue/octue-sdk-python`.
 - Follow the rest of the process for internal developers above.
 - Once checks have passed, test coverage of the new code is 100%, documentation is updated, and the review has passed,
   we'll merge and release your changes.
 
-
 ## Pre-Commit
+
 You need to install pre-commit to get the hooks working. Run:
+
 ```
 pip install pre-commit
 pre-commit install && pre-commit install -t commit-msg
@@ -74,16 +79,18 @@ Upon failure, the commit will halt. **Re-running the commit will automatically f
 - Commit messages - the error messages should explain how to fix these too
 
 You can run pre-commit hooks without making a commit, too, like:
+
 ```
 pre-commit run black --all-files
 ```
+
 or
+
 ```
 # -v gives verbose output, useful for figuring out why docs won't build
 pre-commit run build-docs -v
 ```
 
-
 ## Documentation
 
 ### Building documents automatically
@@ -93,19 +100,20 @@ The documentation will build automatically in a pre-configured environment when
 In fact, the way `pre-commit` works, you won't be allowed to make the commit unless the documentation builds. This way
 we avoid getting broken documentation pushed to the main repository on any commit so we can rely on builds working.
 
-
 ### Building documents manually
 
 **If you did need to build the documentation**
 
 Install `doxygen`. On a mac, that's `brew install doxygen`; other systems may differ.
 
 Install sphinx and other requirements for building the docs:
+
 ```
 pip install -r docs/requirements.txt
 ```
 
 Run the build process:
+
 ```
 sphinx-build -b html docs/source docs/html
 ```

docs/source/asking_questions.rst

@@ -20,7 +20,7 @@ can be:
       `django-twined <https://django-twined.readthedocs.io/en/latest/>`_ or custom logic in your own webserver.
 
 Questions are always asked to a *revision* of a service. You can ask a service a question if you have its
-:ref:`SRUID <sruid_definition>`, project name, and the necessary permissions.
+:ref:`SRUID <sruid_definition>`, project ID, and the necessary permissions.
 
 
 Asking a question
@@ -32,7 +32,7 @@ Asking a question
 
     child = Child(
         id="my-organisation/my-service:2.1.7",
-        backend={"name": "GCPPubSubBackend", "project_name": "my-project"},
+        backend={"name": "GCPPubSubBackend", "project_id": "my-project"},
     )
 
     answer, question_uuid = child.ask(
@@ -241,15 +241,15 @@ if these values are in your service configuration file:
           "id": "template-child-services/wind-speed-service:2.1.1",
           "backend": {
             "name": "GCPPubSubBackend",
-            "project_name": "my-project"
+            "project_id": "my-project"
           }
         },
         {
           "key": "elevation",
           "id": "template-child-services/elevation-service:3.1.9",
           "backend": {
             "name": "GCPPubSubBackend",
-            "project_name": "my-project"
+            "project_id": "my-project"
           }
         }
       ]
@@ -302,15 +302,15 @@ For example, if the child requires these children in its service configuration:
             "id": "template-child-services/wind-speed-service:2.1.1",
             "backend": {
                 "name": "GCPPubSubBackend",
-                "project_name": "octue-sdk-python"
+                "project_id": "octue-sdk-python"
             },
         },
         {
             "key": "elevation",
             "id": "template-child-services/elevation-service:3.1.9",
             "backend": {
                 "name": "GCPPubSubBackend",
-                "project_name": "octue-sdk-python"
+                "project_id": "octue-sdk-python"
             },
         }
     ]
@@ -327,15 +327,15 @@ then you can override them like this:
                 "id": "my/own-service:1.0.0",
                 "backend": {
                     "name": "GCPPubSubBackend",
-                    "project_name": "octue-sdk-python"
+                    "project_id": "octue-sdk-python"
                 },
             },
             {
                 "key": "elevation",
                 "id": "organisation/another-service:0.1.0",
                 "backend": {
                     "name": "GCPPubSubBackend",
-                    "project_name": "octue-sdk-python"
+                    "project_id": "octue-sdk-python"
                 },
             },
         ],
@@ -380,7 +380,7 @@ You can specify service registries in two ways:
 
         child = Child(
             id="my-organisation/my-service:1.1.0",
-            backend={"name": "GCPPubSubBackend", "project_name": "my-project"},
+            backend={"name": "GCPPubSubBackend", "project_id": "my-project"},
             service_registries=[
                 {"name": "my-registry", "endpoint": "blah.com/services"},
             ]