WIP on feature/build-executables

[joshua-quek-sonarsource]

Work in progress. Use Executables and not docker or regular bash

[sonarqube-agent]

Remediation Agent Summary 📊

🤖 To review: The 11 issues found require manual fixes.

Issues requiring manual fix (11)

Quality	Issue	Status
Maintainability 🔴 High	Define a constant instead of duplicating this literal '/app/files/' 4 times. Why is this an issue? Why is this an issue? Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences. Exceptions No issue will be raised on: duplicated string in decorators strings with less than 5 characters strings with only letters, numbers and underscores View this issue in SonarQube Cloud	Unresolved
Maintainability 🔴 High	Define a constant instead of duplicating this literal 'https://api.' 3 times. Why is this an issue? Why is this an issue? Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences. Exceptions No issue will be raised on: duplicated string in decorators strings with less than 5 characters strings with only letters, numbers and underscores View this issue in SonarQube Cloud	Unresolved
Maintainability 🔴 High	Define a constant instead of duplicating this literal 'https://' 3 times. Why is this an issue? Why is this an issue? Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences. Exceptions No issue will be raised on: duplicated string in decorators strings with less than 5 characters strings with only letters, numbers and underscores View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Remove the redundant list constructor call. Why is this an issue? This rule raises an issue when calls to tuple(), list(), set(), or dict() are done with an argument that is either already a collection literal or a comprehension. Why is this an issue? Python provides direct ways to create common data structures like tuples, lists, and dictionaries using literals, e.g., (), (1,2), [], [1,2], {}, {'a':1} and comprehensions e.g., [x for x in y], {k:v for k,v in y}. Wrapping these direct forms in a type constructors is unnecessary, as shown in the following examples: View this code on SonarQube Cloud Such constructs: add overhead by creating an intermediate collections add verbosity without providing any additional functionality add ambiguity and may mislead readers or imply a more complex operation than what is actually occurring Exceptions If there are no modification in the comprehension such as list([x for x in [1,2]]) which is the same as [1,2], this rule will not raise an issue; instead rule S7500 - Comprehensions only used to copy should be replaced with the respective constructor calls, will raise an issue. Resources Documentation Python Documentation - List Comprehensions Python Documentation - Dictionaries Python Documentation - Sets Python Documentation - Tuples and Sequences View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Replace this constructor call with a literal. Why is this an issue? This rule raises an issue when dict(), list(), or tuple() are used to create empty collections or to initialize dictionaries with keyword arguments. Why is this an issue? Python provides concise literal syntax for creating empty dictionaries ({}), lists ([]), and tuples (()). It also offers a direct literal syntax for initializing dictionaries with key-value pairs (e.g., {'a': 1, 'b': 2}). Using the function calls dict(), list(), and tuple() for these purposes is generally less preferred for a few reasons: Readability and Directness: Literals are often considered more "Pythonic" and directly express the intent of creating an empty container or a dictionary with specific initial values. Consistency: Python encourages the use of literals where they are clear and effective. Performance: Calling a function involves overhead, including name lookup for dict, list, or tuple in the current scope. While often negligible for single calls, using literals is a direct instruction to the interpreter and can be marginally faster, especially in performance-sensitive code or tight loops. Specifically, the following patterns are discouraged: Using dict() to create an empty dictionary instead of {}. Using list() to create an empty list instead of []. Using tuple() to create an empty tuple instead of (). Using dict(key='value', …​) to initialize a dictionary instead of {'key': 'value', …​} when keys are simple strings valid as identifiers. While the functional difference is minimal for creating empty collections or simple dictionaries, adopting literals promotes a more direct and idiomatic coding style. Resources Documentation Python Documentation - dict() Python Documentation - list() Python Documentation - tuple() View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Replace this constructor call with a literal. Why is this an issue? This rule raises an issue when dict(), list(), or tuple() are used to create empty collections or to initialize dictionaries with keyword arguments. Why is this an issue? Python provides concise literal syntax for creating empty dictionaries ({}), lists ([]), and tuples (()). It also offers a direct literal syntax for initializing dictionaries with key-value pairs (e.g., {'a': 1, 'b': 2}). Using the function calls dict(), list(), and tuple() for these purposes is generally less preferred for a few reasons: Readability and Directness: Literals are often considered more "Pythonic" and directly express the intent of creating an empty container or a dictionary with specific initial values. Consistency: Python encourages the use of literals where they are clear and effective. Performance: Calling a function involves overhead, including name lookup for dict, list, or tuple in the current scope. While often negligible for single calls, using literals is a direct instruction to the interpreter and can be marginally faster, especially in performance-sensitive code or tight loops. Specifically, the following patterns are discouraged: Using dict() to create an empty dictionary instead of {}. Using list() to create an empty list instead of []. Using tuple() to create an empty tuple instead of (). Using dict(key='value', …​) to initialize a dictionary instead of {'key': 'value', …​} when keys are simple strings valid as identifiers. While the functional difference is minimal for creating empty collections or simple dictionaries, adopting literals promotes a more direct and idiomatic coding style. Resources Documentation Python Documentation - dict() Python Documentation - list() Python Documentation - tuple() View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Replace this constructor call with a literal. Why is this an issue? This rule raises an issue when dict(), list(), or tuple() are used to create empty collections or to initialize dictionaries with keyword arguments. Why is this an issue? Python provides concise literal syntax for creating empty dictionaries ({}), lists ([]), and tuples (()). It also offers a direct literal syntax for initializing dictionaries with key-value pairs (e.g., {'a': 1, 'b': 2}). Using the function calls dict(), list(), and tuple() for these purposes is generally less preferred for a few reasons: Readability and Directness: Literals are often considered more "Pythonic" and directly express the intent of creating an empty container or a dictionary with specific initial values. Consistency: Python encourages the use of literals where they are clear and effective. Performance: Calling a function involves overhead, including name lookup for dict, list, or tuple in the current scope. While often negligible for single calls, using literals is a direct instruction to the interpreter and can be marginally faster, especially in performance-sensitive code or tight loops. Specifically, the following patterns are discouraged: Using dict() to create an empty dictionary instead of {}. Using list() to create an empty list instead of []. Using tuple() to create an empty tuple instead of (). Using dict(key='value', …​) to initialize a dictionary instead of {'key': 'value', …​} when keys are simple strings valid as identifiers. While the functional difference is minimal for creating empty collections or simple dictionaries, adopting literals promotes a more direct and idiomatic coding style. Resources Documentation Python Documentation - dict() Python Documentation - list() Python Documentation - tuple() View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Remove the redundant list constructor call. Why is this an issue? This rule raises an issue when calls to tuple(), list(), set(), or dict() are done with an argument that is either already a collection literal or a comprehension. Why is this an issue? Python provides direct ways to create common data structures like tuples, lists, and dictionaries using literals, e.g., (), (1,2), [], [1,2], {}, {'a':1} and comprehensions e.g., [x for x in y], {k:v for k,v in y}. Wrapping these direct forms in a type constructors is unnecessary, as shown in the following examples: View this code on SonarQube Cloud Such constructs: add overhead by creating an intermediate collections add verbosity without providing any additional functionality add ambiguity and may mislead readers or imply a more complex operation than what is actually occurring Exceptions If there are no modification in the comprehension such as list([x for x in [1,2]]) which is the same as [1,2], this rule will not raise an issue; instead rule S7500 - Comprehensions only used to copy should be replaced with the respective constructor calls, will raise an issue. Resources Documentation Python Documentation - List Comprehensions Python Documentation - Dictionaries Python Documentation - Sets Python Documentation - Tuples and Sequences View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Unpack this comprehension expression Why is this an issue? This rule raises an issue when list comprehensions are used as parameters to any() or all() instead of generator expressions as this prevents any() or all() from short-circuiting. Why is this an issue? Using a list comprehension inside any() or all() forces the entire list to be created in memory before the check begins. This prevents the short-circuiting behavior that these functions are designed to leverage, where any() stops at the first True and all() stops at the first False. Using a generator expression provides the same functionality while preserving the short-circuiting behavior of these functions. This could save both processing time and memory, especially for large iterables or when the condition has side effects or is computationally expensive. Resources Documentation Python Wiki - Generators Python Documentation - Generator Glossary Entry View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Replace this constructor call with a literal. Why is this an issue? This rule raises an issue when dict(), list(), or tuple() are used to create empty collections or to initialize dictionaries with keyword arguments. Why is this an issue? Python provides concise literal syntax for creating empty dictionaries ({}), lists ([]), and tuples (()). It also offers a direct literal syntax for initializing dictionaries with key-value pairs (e.g., {'a': 1, 'b': 2}). Using the function calls dict(), list(), and tuple() for these purposes is generally less preferred for a few reasons: Readability and Directness: Literals are often considered more "Pythonic" and directly express the intent of creating an empty container or a dictionary with specific initial values. Consistency: Python encourages the use of literals where they are clear and effective. Performance: Calling a function involves overhead, including name lookup for dict, list, or tuple in the current scope. While often negligible for single calls, using literals is a direct instruction to the interpreter and can be marginally faster, especially in performance-sensitive code or tight loops. Specifically, the following patterns are discouraged: Using dict() to create an empty dictionary instead of {}. Using list() to create an empty list instead of []. Using tuple() to create an empty tuple instead of (). Using dict(key='value', …​) to initialize a dictionary instead of {'key': 'value', …​} when keys are simple strings valid as identifiers. While the functional difference is minimal for creating empty collections or simple dictionaries, adopting literals promotes a more direct and idiomatic coding style. Resources Documentation Python Documentation - dict() Python Documentation - list() Python Documentation - tuple() View this issue in SonarQube Cloud	Unresolved
Maintainability 🟡 Low	Replace this constructor call with a literal. Why is this an issue? This rule raises an issue when dict(), list(), or tuple() are used to create empty collections or to initialize dictionaries with keyword arguments. Why is this an issue? Python provides concise literal syntax for creating empty dictionaries ({}), lists ([]), and tuples (()). It also offers a direct literal syntax for initializing dictionaries with key-value pairs (e.g., {'a': 1, 'b': 2}). Using the function calls dict(), list(), and tuple() for these purposes is generally less preferred for a few reasons: Readability and Directness: Literals are often considered more "Pythonic" and directly express the intent of creating an empty container or a dictionary with specific initial values. Consistency: Python encourages the use of literals where they are clear and effective. Performance: Calling a function involves overhead, including name lookup for dict, list, or tuple in the current scope. While often negligible for single calls, using literals is a direct instruction to the interpreter and can be marginally faster, especially in performance-sensitive code or tight loops. Specifically, the following patterns are discouraged: Using dict() to create an empty dictionary instead of {}. Using list() to create an empty list instead of []. Using tuple() to create an empty tuple instead of (). Using dict(key='value', …​) to initialize a dictionary instead of {'key': 'value', …​} when keys are simple strings valid as identifiers. While the functional difference is minimal for creating empty collections or simple dictionaries, adopting literals promotes a more direct and idiomatic coding style. Resources Documentation Python Documentation - dict() Python Documentation - list() Python Documentation - tuple() View this issue in SonarQube Cloud	Unresolved

Note

Help us improve the Agent!
Have a suggestion or found an issue? Share your feedback here.

[sonarqubecloud]

SonarQube reviewer guide

Summary: Adds comprehensive build and release automation for standalone executables across multiple platforms (Windows x86_64/ARM64, Linux x86_64/ARM64, macOS Intel/Apple Silicon), along with simplified migration workflows and extensive user documentation.

Review Focus:

• The three GitHub Actions workflows (build-executables.yml, build-windows.yml, release.yml) have overlapping functionality and differing approaches to ARM64 builds—verify which is the canonical/production workflow
• Linux ARM64 cross-compilation via Docker+QEMU (release.yml) should be validated for correctness
• New config file loading in src/main.py and the full_migrate command need verification that they properly merge CLI args with JSON configs and handle all error cases
• PyInstaller spec file (sonar-reports.spec) requires validation that all dependencies are correctly bundled for each platform

Start review at: .github/workflows/release.yml. This is the production release workflow that builds for all six platform combinations and generates GitHub releases. It's important to review first because it defines the authoritative build strategy and should be the single source of truth—the other two workflows appear to be either development/testing variants or redundant, and understanding the production workflow will clarify their purpose and whether consolidation is needed.

💬 Please send your feedback

Quality Gate failed

Failed conditions
6 Security Hotspots
E Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE