RDKB-63002: Native build and Github Action Workflow Changes

[abhishek-kumaracee2]

Reason for change: Coverity check on native build
Test Procedure: Native build successful
Risks: Low
Priority: P1

In general, the fix is to explicitly declare minimal GITHUB_TOKEN permissions for this workflow/job, instead of inheriting potentially broad repository/organization defaults. For a build job that only checks out source and runs local scripts, contents: read is typically sufficient; no write or admin scopes are needed.

The best fix here is to add a permissions block at the job level for build-tr069-protocol-agent-on-pr. This keeps the change localized and ensures only this job is constrained to read-only repository contents. Place the block under the job key (same indentation as name, runs-on, container). Set contents: read, which allows actions/checkout@v3 to function while preventing the workflow from using the default token to push commits, modify releases, or alter other repo resources. No changes are required to existing steps, scripts, or the explicit GITHUB_TOKEN env var, and no imports or new methods are needed because this is a YAML configuration change only.

Concretely, edit .github/workflows/native-build.yml and insert:

    permissions:
      contents: read

between the job’s name: and runs-on: lines (or just after runs-on:, either is valid; we’ll place it after name: for clarity).

[Copilot]

Pull request overview

This PR introduces a generic, reusable native build system (under cov_docker_script/) and a GitHub Actions workflow to build the tr069-protocol-agent component in a native environment suitable for Coverity analysis.

Changes:

• Adds shell scripts and shared utilities to set up dependencies, build the native component, and orchestrate the full pipeline via configuration-driven JSON and conf files.
• Defines component_config.json and configure_options.conf to declare external dependencies, include paths, build flags, and autotools options for tr069-protocol-agent.
• Integrates a new native-build.yml GitHub Actions workflow that runs the dependency setup and native build inside the standard docker-rdk-ci container, plus extensive documentation in cov_docker_script/README.md.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
cov_docker_script/setup_dependencies.sh	Implements config-driven cloning, header copying, and building of dependency repos into $HOME/usr for consumption by the native build.
cov_docker_script/configure_options.conf	Provides structured CPPFLAGS/CFLAGS/LDFLAGS for the autotools build, currently documented as MoCA agent options but used for tr069-protocol-agent.
cov_docker_script/component_config.json	Declares dependency repos (Utopia, common-library, cJSON) and the tr069-protocol-agent native component build configuration, including header paths and build type.
cov_docker_script/common_external_build.sh	Orchestrates the full two-step pipeline (dependency setup + native component build) using the shared utilities and JSON config.
cov_docker_script/common_build_utils.sh	Adds shared helper functions for logging, cloning, header/library copying, patching, and building via autotools/CMake/Meson/command/script.
cov_docker_script/build_native.sh	Configures the build environment, processes component headers, applies native source_patches, runs pre-build commands, builds via autotools/CMake, and installs libraries.
cov_docker_script/README.md	Documents the design, configuration model, usage patterns, and CI/Coverity workflow for the generic native build system, with examples reused from other components.
.github/workflows/native-build.yml	Defines a GitHub Actions workflow that checks out the repo, runs setup_dependencies.sh and build_native.sh inside the docker-rdk-ci container on pushes and PRs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The source_patches entries defined for common-library under dependencies.repos[] are never applied by any of the build scripts: build_native.sh only processes .native_component.source_patches, and setup_dependencies.sh/common_build_utils.sh never read .dependencies.repos[*].source_patches. As a result, the intended DBusLoop typedef injections for ccsp_message_bus.h here will never actually be performed, which can lead to build failures or missing symbols even though the configuration suggests otherwise. To fix this, either move these patches into native_component.source_patches (if they logically belong to the main component) or extend the dependency setup flow to iterate dependencies.repos[*].source_patches and call apply_patch before copying headers or building the dependency.

[Copilot]

copy_python_files_generic flattens all *.py files found under $PYTHON_SRC_DIR into a single destination directory, which means files with the same basename (e.g. multiple __init__.py or common helper names from different repos) will silently overwrite each other. This can lead to unpredictable behavior in pre-build steps that rely on these Python utilities because you may end up running a different module than intended. Consider preserving the directory structure (e.g. recreating relative paths under the destination) or at least detecting and warning on filename collisions instead of overwriting.

[Copilot]

The apply_patch helper directly interpolates the JSON-provided search and replace strings into a Python triple-quoted string ('''$search''', '''$replace'''), which will break as soon as either contains a single quote or certain escape sequences, producing invalid Python syntax or incorrect replacements. Because these patch strings are meant to be arbitrary source fragments, this makes the patching fragile and can cause hard-to-diagnose failures when patches are expanded. A more robust approach would be to escape these strings properly (or pass them via a temporary file or environment variable) so that any valid text, including quotes, can be patched safely.

Suggested change

	if ! python3 -c "
	import sys
	with open('$file', 'r') as f:
	content = f.read()
	content = content.replace('''$search''', '''$replace''')
	with open('$file', 'w') as f:
	f.write(content)
	"; then
	if ! python3 - "$file" "$search" "$replace" << 'PYCODE'
	import sys
	file_path, search, replace = sys.argv[1:4]
	with open(file_path, 'r') as f:
	content = f.read()
	content = content.replace(search, replace)
	with open(file_path, 'w') as f:
	f.write(content)
	PYCODE
	then

[Copilot]

This configuration file is labeled as "MoCA Agent Configure Options" and refers to "the moca-agent component" in the header comment, but in this repository it is wired up to the native_component named tr069-protocol-agent. This mismatch can be confusing when maintaining or reviewing build flags for this component. Please update the header comments to correctly describe that these options are being used for the tr069-protocol-agent (or clarify if the file is intentionally shared between multiple components).

Suggested change

	# MoCA Agent Configure Options
	# This file contains autotools configure options for the moca-agent component
	# tr069-protocol-agent Configure Options
	# This file contains autotools configure options for the tr069-protocol-agent component

[Copilot]

The README documents dependencies.repos[].source_patches[] as a supported feature (see the example under the Dependencies section), but the current shell scripts only process native_component.source_patches and never read or apply dependencies.repos[*].source_patches. This means users following the README to patch dependency sources will see their patches silently ignored. Either document that dependency-level patches are not yet supported, or extend the dependency setup flow to honor dependencies.repos[].source_patches[] so that the README and implementation are consistent.

[abhishek-kumaracee2]

old one - abandon it