Add possibility to specify write-back GIT repository as annotation.

[flozzone]

Addressing #423

This PR does the following:

• Get the repository URL either from app.Spec.Source.RepoURL or from argocd-image-updater.argoproj.io/git-repository if specified and store it into the WriteBackConfig struct as GitRepo.
• Write a test to show git-repository annotation functionality
• Update relevant documentation
• Fix GitHub workflow linting tests by upgrading golangci-lint to its latest version

[CLAassistant]

All committers have signed the CLA.

[flozzone]

Do we need to update something in order to pass linting tests? #413 #410 seem to have a similar problem.

[flozzone]

Do we need to update something in order to pass linting tests? #413 #410 seem to have a similar problem.

Updating to latest version v1.45.2 for the golangci/golangci-lint-action@v2 action fixed linting tests.

[nikodemjedynak-dnv]

@flozzone Any updates on this resolution to the issue? Is it going to be merged? Anyone fancies a review?

[codecov-commenter]

Codecov Report

Merging #424 (79d7ab9) into master (49825ec) will increase coverage by 0.06%. The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master     #424      +/-   ##
==========================================
+ Coverage   65.76%   65.83%   +0.06%     
==========================================
  Files          21       21              
  Lines        2039     2043       +4     
==========================================
+ Hits         1341     1345       +4     
  Misses        569      569              
  Partials      129      129              

Impacted Files	Coverage Δ
pkg/argocd/git.go	64.84% <0.00%> (ø)
pkg/argocd/gitcreds.go	76.19% <83.33%> (ø)
pkg/argocd/update.go	70.28% <83.33%> (+0.48%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[flozzone]

To fix golangci-lint issues I needed to:

Update golangci-lint to 1.52.2

• Replace deprecated linters, deadcode, ,varcheck, structcheck by the newer unused linter. See relevant golangci-lint PR at https://github.com/golangci/golangci-lint/issues/1841
• Run goimports -w -local github.com/argoproj-labs/argocd-image-updater . to fix
  • comment indentation
  • order of imports

[bn-cforkner]

@jannfis bump for this. I know you're probably super busy, but thanks for taking a look

[jannfis]

Thanks for bumping this @bn-cforkner , I'm currently going through the backlog of PRs and issues. I'm really sorry to have been undercover for a while.

Couple of the changes in this PR have been merged recently (i.e. lint update), @flozzone could you please rebase this PR to what's in master? Thanks!

[rwc]

@jannfis @flozzone Hoping to get another look before this gets anymore stale. Would definitely provide some useful function we’re excited to get our hands on.

[LS80]

@flozzone I'm interested in the use case for this. As far as I can tell, the override files would not be used by Argo CD when rendering the manifests so why write the files to a separate git repository?

[joshbrgs]

@flozzone I'm interested in the use case for this. As far as I can tell, the override files would not be used by Argo CD when rendering the manifests so why write the files to a separate git repository?

@LS80 I know a use case it could be handy for is when you want git write back method and are using an OCI storage for your charts.

[LS80]

@LS80 I know a use case it could be handy for is when you want git write back method and are using an OCI storage for your charts.

Yes but I'm not sure what use the git write back method has if the override files created/updated in git will not actually be used by Argo CD. If an Argo CD application could be configured to use override files from a repo other than the one specified as source.repoURL then it would be really useful. I've just remembered that we can now have multiple sources so maybe that would work. One repoURL for the parameter override files in git and another referencing the helm repo...

[rwc]

@LS80 We use it as a record of deployment in environments where the origin of what’s running must be certified/tracked for compliance reasons.