CLI-1388: Error on push:artifacts when source and destination tag values are the same.

[gambry]

Describe the bug
In scenario where development team want for the same tagged releases to be used in the development git repo and in AC tags' list, the team can have something like this in their CI/CD:

acli push:artifact --source-git-tag=**1.1.0** --destination-git-tag=**1.1.0** --no-interaction --verbose

Is not however possible to use the same source and destination tag values, since doing it generate the below error:

error: src refspec 1.1.0 matches more than one

This is because push:artifact command initially create a branch with --source-git-tag value and eventually a tag with --destination-git-tag value. At the moment of pushing, the pushed ref is both a branch and a tag and git returns an error

To Reproduce
Steps to reproduce the behavior:

1. Run acli push:artifact --source-git-tag=$any-source-tag --destination-git-tag=$same-value-as-source-git-tag --no-interaction --verbose

Expected behavior
The tag should correctly be pushed to acquia remote, or an error should be raised that --source-git-tag and --destination-git-tag values MUST not be the same.

[danepowell]

Maybe there's a misunderstanding of the purpose of --source-git-tag here. It doesn't refer to the source repository. It refers to source branch (or tag, obviously, but I think it should be renamed to source-git-branch) on the destination or artifact (Acquia Cloud) repository.

In other words, when building the artifact, if you don't provide a --source-git-tag, ACLI will basically push a dangling commit. That commit will contain no history and may not be very space-efficient.

Providing a --source-git-tag causes the new commit to happen on top of an existing branch/tag in the destination git repo, so it preserves Git history and is probably more space efficient if it shares most code with the previous commit.

In this model, I can't see any reason why the source git tag and destination git tag should be the same.

[danepowell]

@gambry would it help if we rename --source-git-tag to --source-git-branch, --source-git-ref, or --parent-ref, and add an explicit error if it's the same as --destination-git-tag?

I'm wondering how we can make it more explicit that --source-git-x (however we choose to name it), refers to a parent commit on the destination repository and has nothing to do with the source repository.

[gambry]

Let's tackle this from a technical requirement point of view.

It's standard practice to cut releases using git tags against the development git repository. Also is standard practice that creating a release tag (i.e. using format v1.2.3) triggers a CI/CD job that compiles the codebase for production and deploy it to whatever target Prod environments the application is meant to be deployed to.

So what I expect for these options to do is to allow teams to have the same release tag used in he development git repository and in Acquia Cloud's repository. This is to be able to trace changes.

In other words, when building the artifact, if you don't provide a --source-git-tag

I'd agree with you, but unfortunately --source-git-tag is required when using --destination-git-tag :( And the documentation didn't help understanding this concept: "The source tag from which to create the tag artifact".

would it help if we rename --source-git-tag to --source-git-branch

Why not removing that option completely and give the ability to use --destination-git-branch together with --destination-git-tag?
The former could be optional, and if not provided to default to the main branch. Which is the default behavior when you git clone a repo.
The later simply add to the default push:artifacts the ability to create and push a tag against the same commit.

Thoughts?

[danepowell]

Would something like this make sense? #1801