rnafusion HK tags as constants

[fevac]

Description

Closes #2743

Changed

• Use constants for rnafusion HK tags instead of strings

How to prepare for test

• Ssh to relevant server (depending on type of change)
• Use stage: us
• Paxa the environment: paxa
• Install on stage (example for Hasta):

  bash /home/proj/production/servers/resources/hasta.scilifelab.se/update-tool-stage.sh -e S_cg -t cg -b delivery_constants -a

How to test

• cg upload -c RNAFUSION_CASE. Make sure it's successful

Expected test outcome

• Check that ...
• Take a screenshot and attach or copy/paste the output.

Review

• Tests executed by
• "Merge and deploy" approved by
  Thanks for filling in who performed the code review and the test!

This version is a

• MAJOR - when you make incompatible API changes
• MINOR - when you add functionality in a backwards compatible manner
• PATCH - when you make backwards compatible bug fixes or documentation/instructions

Implementation Plan

• Document in ...
• Deploy this branch on ...
• Inform to ...

[diitaz93]

Looks good 🙌

[islean]

Looks good! A bit unsure what the scope is - should all instances be switched or is that for a separate PR in some future?

[ivadym]

I'm not particularly keen on adding these constants, mainly because they make it more difficult to visualise which set of tags we are delivering and further expand the problem of having the tag logic in two different places, Hermes and CG.

Perhaps this issue needs to be further refined:

• Are these constants file-specific? I don't think so. Should they be? I don't know. Maybe having constants for file names that are assigned a bunch of tags isn't a bad idea.
• Why are we having this logic on both sides (Hermes and CG) and not using the deliver tag that we add in Hermes?
• If we use the deliver tag, how do we differentiate between deliver-sample and deliver-case? Perhaps that's what we need to actually fix and deliver using only those two tags.

[fevac]

I'm not particularly keen on adding these constants, mainly because they make it more difficult to visualise which set of tags we are delivering and further expand the problem of having the tag logic in two different places, Hermes and CG.

@ivadym This pr only replaces strings by constants and I don't think the use of constants make it more difficult to visualize which set of tags are used. It's the opposite to me and it also makes it easier to pinpoint tags that should be the same. I agree that the duplication between hermes and cg is a problem and should be revisited but this PR doesn't expand the problem further.

Perhaps this issue needs to be further refined:

• Are these constants file-specific? I don't think so. Should they be? I don't know. Maybe having constants for file names that are assigned a bunch of tags isn't a bad idea.

Some are some are not. I don't think how this is relevant for this.

• Why are we having this logic on both sides (Hermes and CG) and not using the deliver tag that we add in Hermes?

I don't know and I fully agree. But that is 100% out of the scope of this PR

• If we use the deliver tag, how do we differentiate between deliver-sample and deliver-case? Perhaps that's what we need to actually fix and deliver using only those two tags.

Good point

I do agree duplication between cg and hermes should be addressed, but in the meantime. Should I leave this as constant or strings? I don't mind which way. I do see benefit of removing strings that are redundant but I don't really care one way or another.

[ivadym]

Some are some are not. I don't think how this is relevant for this.

For me it would make more sense to define files as constants that contain a set of tags. But as you said, some are file specific, some are not. And it's out of scope of this PR 🙃

I do agree duplication between cg and hermes should be addressed, but in the meantime. Should I leave this as constant or strings? I don't mind which way. I do see benefit of removing strings that are redundant but I don't really care one way or another.

I think you should proceed with it. Although it doesn’t add any additional semantic meaning it will help to keep our coding style consistent

And thanks for opening the issue ⭐

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[fevac]

tests are passing

[fevac]

Deployed in stage

Deployed in prod