fetch tags to local, if different to remote

[tmu-sprd]

We have the use case, that r10k is pulling modules from our own Git and some modules are applied via puppet apply based on a tag in the Git repository. Therefore it's needed, that the git tags are also updated in the deployed modules by r10k.

This PR adds updating the tags, when they differ local and remote.
This is running currently in our production and is working fine.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

This PR has been marked stale because it has had no activity for 60 days. If you are still interested in getting this merged, please comment and we'll try to move it forward. Otherwise, it will be closed in 7 days.

[tmu-sprd]

Is there anything, I can do, to bring this forward?

[justinstoller]

Sorry, I missed this.

The change looks good, but let me double check the prune => true behavior won't break any use cases.

[github-actions]

This PR has been marked stale because it has had no activity for 60 days. If you are still interested in getting this merged, please comment and we'll try to move it forward. Otherwise, it will be closed in 7 days.

[tmu-sprd]

I'm still interested to get this merged. Just commenting, to remove the stale label.

[github-actions]

This PR has been marked stale because it has had no activity for 60 days. If you are still interested in getting this merged, please comment and we'll try to move it forward. Otherwise, it will be closed in 7 days.

[tmu-sprd]

Still interested.

[github-actions]

This PR has been marked stale because it has had no activity for 60 days. If you are still interested in getting this merged, please comment and we'll try to move it forward. Otherwise, it will be closed in 7 days.

[tmu-sprd]

And again: Still interested

[bastelfreak]

@tmu-sprd I'm not sure if I understand your usecase. Does that mean that you delete and recreate tags, that then point to a different commit?

[nabertrand]

While our use case doesn't involve tags as @tmu-sprd describes, I'm hoping the --prune flags added in this PR will fix the frequent fatal: bad object refs/remotes/cache/XXX errors we see when deploying environments as described in #1399

[bastelfreak]

(I am not employed by Perforce, but I've some thoughts)

I'm totally fine with adding the prune option. And that should probably be it's own PR, because it's a bugfix.

---

I'm not sure about updating the tags / comparing them. For years, we taught people to rely on git tags or commits in their Puppetfile when they want to speed up deployments. The assumption was that those are immutable. Because of that, r10k has the incremental option to check if the deployed modules match the tags/commits in the Puppetfile. This assumption breaks when tags are manipulated on the gitserver. I'm not sure if that's something we should support.

[tmu-sprd]

Thanks for replying and I'll try to describe the use case.

Our Delivery Engineering team use git tags to deploy applications via Puppet. In the source repository there is Puppet code to deploy the applications to Kubernetes, QA, VMs etc. When a new version of an application is ready for deployment a SemVer version tag is added to the feature branch and then this is merged to the main branch. The main branch is referenced in the Puppetfile.
When this tag is added, a CI pipeline starts, which builds the application with the tag version and pushes it to the binary repository. Additionally r10k is triggered via webhook to deploy the source repo as Puppet module. There are custom Puppet functions in place, which evaluate the tags on the Puppet server during catalog compilation and deploys the latest tag version from the binary repo.

By this, it's not needed to change any Puppet code, YAML or Puppetfile to deploy a new version of an app. Just add the new version tag and the app is deployed.

For this to work, it's needed, that the tags are synchronized at the Puppet server. Hence this PR.

I hope, this makes sense.