Docker image showing "dirty" tag after modifying run_locally.sh

[srikarBudda]

Context:
While running the monitoring suite locally, we noticed that the Docker image tag is being marked as dirty(e.g., v0.20.0-dirty). The only local modifications we made were:

1. Updating run_locally.sh to fix a small issue(see below) in the docker run command and to adjust the AUTH_SPEC configuration.
2. Updating uss2.libsonnet with our base URLs.

The above is the issue we saw associated with the docker run command and was later fixed by doing the below fix.

After these changes, everything runs fine, but the image tag now consistently appears as dirty even though the repository has no other changes other than the two above.

This is the snapshot of the changes. The others are just the files that are being requested here to be present to run the configuration.

Question:

1. Is there a known reason why updating run_locally.sh would cause the docker image to be marked as "dirty"?
2. Could this behavior be tied to how the script interacts with the repo during build or run?
3. And is there a recommended way to avoid the "dirty" tag when making small local script fixes like this?

[BenjaminPelletier]

run_locally.sh is a file tracked by git in this repository. "dirty" is an indication that there are local changes to git-tracked files which have not been committed -- so, v0.20.0-dirty means "this software is based on v0.20.0, but it has some uncommitted changes". This is important information because changes to the codebase can cause different behavior -- to anticipate and debug behavior, it's important to know whether exactly v0.20.0 is running, or if there are some modifications that could potentially be causing the problem.

It can be quick to modify existing configuration files in place to create a test configuration that fits a need, but for production usage, the way to create a test configuration is to put it in the personal folder or some external location. Changes to the CI test configuration components are also changes to git-tracked files and will result in "dirty" as well, which is why the personal folder is recommended (if not referencing an external location).

If a user wants to make minor changes to a known configuration that has many $ref/import components (definition spread across many files), this starting configuration can be rendered into a single configuration file (similar to f3548_self_contained) using the --config-output uss_qualifier flag rather than trying to move all components over personal or a separate location.

MSYS_NO_PATHCONV=1 seems like a useful Windows-compatibility addition along with #1251, but adding it does change the canonical codebase until it's merged to the main branch, and that is indicated by "-dirty".

run_locally.sh is another git-tracked file. If a user needs to run a custom script, simply make sure that custom script isn't considered git-tracked. For instance, making a copy of run_locally.sh in uss_qualifier/configurations/personal could be one way to maintain a custom script.

[BenjaminPelletier]

I believe this question has been answered, but feel free to reopen if not.