fix: more robust config file modifications in install-deadline-worker

[jusiskin]

What was the problem/requirement? (What/Why)

Background

The worker agent provides a install-deadline-worker CLI command that is used for setting up a worker host. The command accepts configuration settings in its command-line arguments for configuration settings to be applied. Those settings are applied by modifying the worker agent configuration file (docs), which uses the TOML file format.

Problem

The code for modifying the worker agent configuration file used simple pattern matching and replacement. For Linux, the sed command was used. On Windows, Python's re.sub(...) was used.

This implementation is fragile and comes with multiple issues:

1. Any trailing inline TOML comments, for example:

   [worker]
   farm_id = "farm-123"  # our staging farm

   could cause the pattern matching to fail

2. If the pattern matching allows for trailing comments, the replacement may not preserve them after modification.

3. The patterns may be overly-strict, for example:

   deadline-cloud-worker-agent/src/deadline_worker_agent/installer/install.sh

   Lines 411 to 412 in c26590d

   	-e "s,^# farm_id\s*=\s*\"REPLACE-WITH-WORKER-FARM-ID\"$,farm_id = \"${farm_id}\",g" \
   	-e "s,^# fleet_id\s*=\s*\"REPLACE-WITH-WORKER-FLEET-ID\"$,fleet_id = \"${fleet_id}\",g" \

   Which is the root cause of Running install-deadline-worker with a previous farm and fleet configured fails #308

4. If the config file exists but some settings are not defined or commented out, the configuration cannot be applied. One example is when a new setting is introduced to the config file (feat: configurable session root directory #513). In such cases, the current implementation of install-deadline-worker will not be able to find an existing setting and fail.

What was the solution? (How)

Added tomlkit as a dependency. This is a Python package that allows for modifying TOML documents while preserving style (comments, blank space, ordering, indentation, etc...).

Functionality was added to deadline_worker_agent.config.config_file.ConfigFile to modify settings for a tomlkit document (or alternatively specifying a path to a config file and tomlkit is used to modify it).

The logic for modifying settings has the following algorithm:

flowchart LR

A((Start)) -->|Set| B{Exists?}
A -->|Unset| C{Exists?}
B -->|Exists| D[Modify]
D --> H((Done))
B -->|Commented out| E[Uncomment and set value]
E --> H
B -->|Does not exist| F[Create with doc comments]
F --> H
C -->|Exists| G[Comment out]
G --> H
C -->|Does not exist| H

Loading

This code was integrated into the install-deadline-worker logic. Of particular note, the Linux implementation of install-deadline-worker runs a bash script (install.sh) in a subprocess which handles the installation logic. To integrate with the new Python logic for TOML config file modification, a command-line interface was added to src/deadline_worker_agent/config/__main__.py.

The path to the Python interpreter is passed as an argument to install.sh which is used to invoke this Python command-line interface:

${python_interpreter_path} -m deadline_worker_agent.config ...

What is the impact of this change?

1. The install-deadline-worker command uses more robust code for modifying the worker agent configuration file and preserving style and comments of the TOML document.
2. Can use the install-deadline-worker to change the farm and fleet ID of an existing worker agent config file (fixes Running install-deadline-worker with a previous farm and fleet configured fails #308)

How was this change tested?

1. Integration tests were added for the newly added Python functions and the deadline_worker_agent.config command-line interface. I've expanded the GitHub workflows to also run integration tests on Ubuntu (they were previously just run on Windows)
2. I ran the worker agent end-to-end tests which succeeded.

Was this change documented?

No, this is mostly fixing our implementation and has more robust behavior for edge cases.

Is this a breaking change?

No

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jusiskin]

There are "expected checks" (docs) that are still waiting here.

This is because this PR changes the name of the checks (see .github/workflows/code_quality.yml). Once I have review approvals and we are ready to merge this, we will modify the branch protection rules for mainline to reflect the new check names.