Minor updates to CI pipeline to bring it into alignment with CI workflow and docker compose .ymls

CI_CD_PIPELINE_SETUP_GUIDE.md

@@ -899,8 +899,6 @@ sudo chown CI_SERVICE_USER:CI_SERVICE_USER /etc/forgejo-runner/.runner
 sudo chmod 600 /etc/forgejo-runner/.runner
 ```
 
-
-
 **What this does**:
 - Copies the configuration to the system location (`/etc/forgejo-runner/.runner`)
 - Sets proper ownership and permissions for CI_SERVICE_USER to access the config
@@ -950,11 +948,6 @@ sudo systemctl status forgejo-runner.service
 
 **Expected Output**: The service should show "active (running)" status.
 
-**What this does**: 
-- Starts the Forgejo runner daemon as a system service
-- The runner will now be available to accept and execute workflows from your Forgejo instance
-- The service will automatically restart if it crashes or the system reboots
-
 #### 6.4 Test Runner Configuration
 
 ```bash
@@ -985,7 +978,6 @@ sudo journalctl -u forgejo-runner.service -f --no-pager
 
 #### 7.1 Create Containerized CI/CD Environment
 
-
 ```bash
 # Switch to CI_SERVICE_USER (who has Docker group access)
 sudo su - CI_SERVICE_USER
@@ -1016,7 +1008,6 @@ docker exec ci-dind docker version
 
 #### 7.2 Configure DinD for Harbor Registry
 
-
 ```bash
 # Navigate to the application directory
 cd /opt/APP_NAME
@@ -1718,14 +1709,17 @@ The pipeline should execute these steps in order:
 
 ```bash
 # On CI/CD Linode
-cd /opt/APP_NAME/registry
+cd /opt/APP_NAME
 
-# Check if new images were pushed
-curl -k https://localhost:8080/v2/_catalog
+# Check if new images were pushed (using correct Harbor port 443)
+curl -k https://localhost:443/v2/_catalog
 
-# Check specific repository tags
-curl -k https://localhost:8080/v2/public/backend/tags/list
-curl -k https://localhost:8080/v2/public/frontend/tags/list
+# Check specific repository tags (using correct Harbor API structure)
+curl -k https://localhost:443/v2/APP_NAME/backend/tags/list
+curl -k https://localhost:443/v2/APP_NAME/frontend/tags/list
+
+# Alternative: Check Harbor web UI
+# Open https://YOUR_CI_CD_IP in your browser and navigate to Projects → APP_NAME
 ```
 
 #### 18.4 Verify Production Deployment
@@ -1735,15 +1729,15 @@ curl -k https://localhost:8080/v2/public/frontend/tags/list
 cd /opt/APP_NAME
 
 # Check if containers are running with new images
-docker compose ps
+docker compose -f docker-compose.prod.yml ps
 
 # Check application health
 curl http://localhost:3000
 curl http://localhost:3001/health
 
 # Check container logs for any errors
-docker compose logs backend
-docker compose logs frontend
+docker compose -f docker-compose.prod.yml logs backend
+docker compose -f docker-compose.prod.yml logs frontend
 ```
 
 #### 18.5 Test Application Functionality
@@ -1889,24 +1883,28 @@ Your application is now ready for continuous deployment with proper security, mo
 - Test failures stop the pipeline before any images are built or deployed.
 - Only tested images are deployed to production.
 
-
 ### Manual Testing with docker-compose.test.yml
 
 You can use the same test environment locally that the CI pipeline uses for integration testing. This is useful for debugging, development, or verifying your setup before pushing changes.
 
-#### Start the Test Environment
-```bash
-docker compose -f docker-compose.test.yml up -d
-```
-This will start all services needed for integration tests (PostgreSQL, backend, frontend, etc.) in the background.
+**Note**: Since the CI pipeline runs tests inside a DinD container, local testing requires a similar setup.
+
+#### Start the Test Environment (Local Development)
+
+For local development testing, you can run the test environment directly:
 
-#### Check Service Health
 ```bash
+# Start the test environment locally
+docker compose -f docker-compose.test.yml up -d
+
+# Check service health
 docker compose -f docker-compose.test.yml ps
 ```
-Look for the `healthy` status in the output to ensure all services are ready.
+
+**Important**: This local setup is for development only. The CI pipeline uses a more isolated DinD environment.
 
 #### Run Tests Manually
+
 You can now exec into the containers to run tests or commands as needed. For example:
 ```bash
 # Run backend tests
@@ -1922,4 +1920,4 @@ When you're done, stop and remove all test containers:
 docker compose -f docker-compose.test.yml down
 ```
 
-**Tip:** This is the same environment and process used by the CI pipeline, so passing tests here means they should also pass in CI.
+**Tip:** The CI pipeline uses the same test containers but runs them inside a DinD environment for complete isolation.