05.07.Remove Hardcodings.spec

05.07. Remove Hardcodings.spec

This document provides a comprehensive analysis of hardcoded values within the /opt/bnc/ repositories and specifies the requirements and strategy for their removal to ensure the project remains a portable, forkable template.

1. Executive Summary

A scan of the bnc-cpt repositories reveals significant use of hardcoded absolute paths, environment-specific URLs, personal email addresses, and organization/application identifiers. These practices violate the project's core mandate of never hardcoding ORG, APP, or derived paths, making the project difficult to fork or rename.

2. Identified Hardcoding Categories

2.1 Absolute File Paths

Problem: Extensive use of /opt/bnc/bnc-cpt/... and /home/ysg/... in shell scripts, Dockerfiles, and documentation. * Examples: * /opt/bnc/bnc-cpt/bnc-cpt-api * /home/ysg/.gcp/.bnc/key-bnc-cpt-inf.json * Risk: Breaks portability. Scripts fail if the project is moved to a different directory or user.

2.2 Environment-Specific URLs

Problem: Hardcoded URLs for dev, tst, and prd environments in documentation and some integration scripts. * Examples: * https://dev.api.carpulsetracker.com * https://inf.carpulsetracker.com/git-report/index.html * Risk: Requires manual search-and-replace for every new application or environment change.

2.3 Personal Identities (Emails & Names)

Problem: Hardcoded email addresses and names in script parameters, commit messages, and documentation. * Examples: * yordan.georgiev@csitea.net * ext-yordan.georgiev@futurice.com * Risk: Inappropriate for a template; leaks personal information and ties the codebase to a specific person.

2.4 Organization & Application Strings

Problem: Direct use of "bnc" and "cpt" in file paths and variable names instead of derived variables. * Examples: * bnc-cpt-all-relay * key-bnc-cpt-dev.json * Risk: Prevents the do_morph_full_project automation from correctly rebranding the project.

3. How-To: Removal and Refactoring Strategy

3.1 Resolving Absolute Paths

Action: Use the existing variable framework (ORG, APP, APP_PATH, PROJ_PATH) provided by run.sh. * Before: cp /opt/bnc/bnc-cpt/bnc-cpt-api/file.txt /tmp/ * After: cp "${APP_PATH}/${ORG}-${APP}-api/file.txt" /tmp/ * Home Paths: Use $HOME instead of /home/ysg. * Refactored Key Path: $HOME/.gcp/.${ORG}/key-${ORG}-${APP}-${ENV}.json

3.2 Dynamic URL Generation

Action: Derive FQDNs from the configuration YAMLs using yq or project-standard variables. * Implementation: Create a central helper function do_get_fqdn() that reads from cnf/bnc-cpt/${ENV}.env.yaml. * Documentation: Use placeholders like https://{{dev_api_fqdn}} in templates.

3.3 Generic Identities

Action: Replace hardcoded emails with variables or placeholders. * Git Config: Use $(git config user.email) in scripts. * GCP Accounts: Use GCP_ACCOUNT environment variable.

3.4 Command-Line Arguments

Action: Ensure all shell actions use do_parse_args to accept overrides instead of relying on hardcoded defaults within the function body.

4. Implementation Plan

Step 1: Core Shell Scripts (utl/crs)

Review run.sh and *.func.sh files.
Replace all occurrences of /opt/bnc with ${BASE_PATH}/${ORG} or ${APP_PATH}.
Replace all /home/ysg with ~ or $HOME.

Step 2: Documentation (doc/md)

Convert concrete example paths into templated paths.
Update README.md and DEV.md files to use ${ORG} and ${APP} in code blocks.

Step 3: CI/CD Workflows

Ensure GitHub Actions use vars.ORG and vars.APP.
Audit the DOCKER_IMAGE_NAME and GCP_PROJECT_ID derivations.

5. Validation

After refactoring, run the following validation: 1. grep -r "/opt/bnc" . should return zero hits in executable code. 2. grep -r "yordan.georgiev" . should be restricted to git log or specific attribution fields, not functional logic. 3. Test a "Project Morph" to verify that changing ORG and APP variables results in a fully functional, rebranded set of repositories.