fix: use label for robustness

[a-zw]

📌 Description

Label() is the best way to specify targets "relative to lexically-here". For contrast, something like "//foo:bar" is "relative to dynamically-here" and fails if one executes rules from another module. It is mostly equivalent to "@my_module//foo:bar" but avoids repeating the current module name. It also works when module names are remapped (but afaik nobody does that yet in S-CORE).

Also, fix two occasions where code might break if labels are involved.

See https://bazel.build/rules/lib/builtins/Label for context.

🚨 Impact Analysis

• This change does not violate any tool requirements and is covered by existing tool requirements
• This change does not violate any design decisions
• Otherwise I have created a ticket for new tool qualification

✅ Checklist

• Added/updated documentation for new or changed features
• Added/updated tests to cover the changes
• Followed project coding standards and guidelines

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //src:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: cfe5d92f-4141-43ed-b8de-21af1a8cc35a
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: src
WARNING: Target pattern parsing failed.
ERROR: Skipping '//src:license-check': no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
ERROR: no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
INFO: Elapsed time: 5.574s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

[github-actions]

The created documentation from the pull request is available at: docu-html

[AlexanderLanin]

@a-zw can you explain why this is better?

[MaximilianSoerenPollak]

@a-zw can you explain why this is better?

He specified this in another chat:

Label() is the best way to specify targets "relative to lexically-here". For contrast, something like "//foo:bar" is "relative to dynamically-here" and fails if one executes rules from another module. It is mostly equivalent to "@my_module//foo:bar" but avoids repeating the current module name. It also works when module names are remapped (but afaik nobody does that yet in S-CORE).

[AlexanderLanin]

So the argument is Label is more readable then @score_docs_as_code?

[a-zw]

@MaximilianSoerenPollak I added that to the description (assuming that it ends up in the merge commit).

@AlexanderLanin It is not about readability but about robustness. If we rename the module, Label just keeps working. If someone renames the module when importing it, Label just keeps working.

It is not a critical thing because I don't see any of these things happening in the near future. It looks like a good practice though.

[AlexanderLanin]

assuming that it ends up in the merge commit)

It links to this PR anyway, so thats fine.