fix(updatecli): use values file

[v1v]

What does this PR do?

Use the scm values file to be able to know what's the GH repository where those changes should be applied.

Why is it important?

Keep the automation doing what it was aimed to do :)

#5367 introduced a regression when replaced the hardcoded values for the values in a file. It's required to pass the new values file to the updatecli apply command, that's something I missed to do it.

Test

I ran the below command

$ GITHUB_TOKEN=$(gh auth token) \
   GITHUB_ACTOR=updatecli \
   updatecli apply --config .ci/updatecli/updatecli-bump-golang.yml --values .ci/updatecli/values.d/scm.yml --push=false


+++++++++++
+ PREPARE +
+++++++++++

Loading Pipeline ".ci/updatecli/updatecli-bump-golang.yml"

...

Run Summary
===========
Pipeline(s) run:
  * Changed:	0
  * Failed:	0
  * Skipped:	0
  * Succeeded:	1

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

How to test this PR locally

Related issues

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[blakerouse]

Can you provide a little more context on what this is doing? I don't fully understand.

[v1v]

Can you provide a little more context on what this is doing? I don't fully understand.

Sure thing.

When I refactored the updatecli pipelines in #5367

I changed the hardcoded values for the values in .ci/updatecli/values.d/scm.yml.

Unfortunately, I didn't test whether GitHub workflow changes worked as planned.

In other words, I introduced a regression when I refactored the updatecli pipelines to be able to use the updatecli policies and reuse some of those variables between the different tupdatecli pipelines.

[blakerouse]

Thanks for the details. Makes sense now.

[v1v]

/test

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube