Automated tag deployments on Travis CI fail with 'src refspec matches more than one`

[geerlingguy]

$ blt version
blt > version:
     [echo] BLT version is 8.6.14

When I create a tag in the source repository, and Travis CI builds that tag, I get the following output and a build failure in Travis CI:

     [exec] Executing command: 'git' 'commit' '--quiet' '-m' 'Automated commit by Travis CI for Build 1.5.1'
     [exec] Executing command: cat /home/travis/build/acquia-pso/projectname/blt/.schema_version 2>&1
     [exec] Executing command: composer info acquia/blt --no-ansi 2> /dev/null | grep versions | awk '{print $4}' 2>&1
blt > deploy:tag:
     [exec] Executing command: git tag -a 1.5.1-build -m 'Automated commit by Travis CI for Build 1.5.1'
     [exec] Executing command: cat /home/travis/build/acquia-pso/projectname/blt/.schema_version 2>&1
     [exec] Executing command: composer info acquia/blt --no-ansi 2> /dev/null | grep versions | awk '{print $4}' 2>&1
blt > deploy:push-all:
     [exec] Executing command: cat /home/travis/build/acquia-pso/projectname/blt/.schema_version 2>&1
     [exec] Executing command: composer info acquia/blt --no-ansi 2> /dev/null | grep versions | awk '{print $4}' 2>&1
blt > deploy:push-remote:
     [exec] Executing command: git push b2897977cba189c4e34f1e5699d47dfb 1.5.1-build 2>&1
     [exec] error: src refspec 1.5.1-build matches more than one.
     [exec] error: failed to push some refs to 'projectname@svn-12345.prod.hosting.acquia.com:projectname.git'

Normal PR merge builds succeed in pushing artifacts to the master-build branch.

[geerlingguy]

It looks like during the git:pull operation, a branch is created with the exact same name:

blt > deploy:remote:pull:
     [exec] Executing command: git fetch b2897977cba189c4e34f1e5699d47dfb 1.5.1-build
Warning: Permanently added the RSA host key for IP address '54.81.8.61' to the list of known hosts.
fatal: Couldn't find remote ref 1.5.1-build
fatal: The remote end hung up unexpectedly
     [exec] Executing command: git checkout -b 1.5.1-build
Switched to a new branch '1.5.1-build'
merge: b2897977cba189c4e34f1e5699d47dfb/1.5.1-build - not something we can merge

And thus the git error message during deploy:push-remote makes sense.

[grasmash]

Here's a real world scenario. We'd like to make a new release for prod using HEAD on master. We need to build our artifact and cut tags.

We want:

1. A tag for HEAD on the master branch, which is not a build artifact.
2. A branch containing the build artifact generated from HEAD on master
3. A tag for the build artifact generated from HEAD on master

So, we need default names for:

1. The tag on the source repo
2. The branch used for building the artifact
3. The tag for the artifact

I'd suggest:

1. 1.0.0-source
2. 1.0.0-build
3. 1.0.0

Currently 2 and 3 are conflated.

Other idea:

1. 1.0.0
2. 1.0.0-build-branch
3. 1.0.0-build

@geerlingguy @danepowell thoughts?

@unn I'd also like your input. It seems that we should be somewhat consistent with Pipelines.

[geerlingguy]

@grasmash - I like:

Source: 1.0.0
Build branch: 1.0.0-build-branch
Build tag: 1.0.0-build

[danepowell]

I guess I'm not clear on how you ended up with a branch and tag that have the same names.

We use the following naming convention to avoid any chance of this:

• Code gets merged to master in Github, and deployed to master-build.
• We cut release branches from master and name them like release-3.1.x (that would be Sprint 3, release 1, with the 'x' indicating the possibility of a hotfix)
• We tag releases on those branches (in this example, 3.1.0 would be the initial release. If we have to hotfix it, the hotfix would be 3.1.1).

We've also tweaked the Travis deploy step to support this:
-Ddeploy.branch="release-$(echo $TRAVIS_TAG | cut -d. -f1).$(echo $TRAVIS_TAG | cut -d. -f2).x"

I'm open to other standards, but note that this is part of our technical architecture document template so we'd want to coordinate on a change.

[geerlingguy]

@danepowell - In the case of the two projects I'm on, for releases we just tag master, and the tagging standard isn't really the same between projects as far as I can tell... sometimes it's [major initiative].[sprint].[release-number], other times it's [sprint].[release].[whatever-someone-decides]`...

But anyways, the tags for many projects are cut straight from master (then for hotfixes, a branch is created from that tag).

So we have:

Source branches:

• master

Acquia Cloud artifact branches:

• master-build

Source tags:

• 1.0.0
• 1.1.0 ...

Acquia Cloud artifact tags:

• 1.0.0-build
• 1.1.0-build ...

The BLT setup would also add in a branch per tag to the artifact repo; I don't really care for these branches, and prune them from time to time (since they don't correspond to any branch in the source repo, and just make the list of tags super long in AC's interface).

[grasmash]

Maybe the right answer is to simply never push the "build branch" when a tag is being cut.

[geerlingguy]

Looks great!

[danepowell]

I was wary of this at first, but I guess as long as we can continue to have tagged release branches on the source repo that's okay. Ideally the build repo is just a place to push code snapshots, and not someplace you actually do development, so you shouldn't need branches in the build repo...

[grasmash]

@geerlingguy Actually, this doesn't work because on the travis worker we're still using the same name for the branch and tag. So, we need a new naming convention.

[grasmash]

Submitted #1171