use lightweight tags on gerrit to provide moving codename targets

Bug #995604 reported by Monty Taylor on 2012-05-06
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Core Infrastructure

Bug Description

git repos support the idea of a symbolic-ref, which is like a symlink. What we'd like it to see if we can manage these from the gerrit side (probably directly on the filesystem git repos) so that we can have a symbolic-ref called "folsom" which points right now to master, and when folsom is in RC stage, points to milestone-proposed, and when it's released points to stable/folsom.

Need to ensure that changes to master don't doulbe-trigger things. If this works, we'll want to hook this in to the release process, either by documenting a step for thierry, or making a tool somewhere which does this work, or both.

Monty Taylor (mordred) wrote :

I think first step is just to try adding a symbolic-ref directly on one of the git repos on the filesystem and see if gerrit serves it/understands it properly if that works, probably a puppet script/yaml entry that makes the refs

Changed in openstack-ci:
importance: Low → High
milestone: folsom → grizzly
Jeremy Stanley (fungi) on 2012-09-24
Changed in openstack-ci:
assignee: nobody → Jeremy Stanley (fungi)
status: Triaged → In Progress
Monty Taylor (mordred) wrote :

Use cases:
 - soren would like to develop something based on "folsom" He would like to start developing that thing before folsom is released, so he would like to point his automated testing scripts to grab the folsom code base, build it, test it and deploy it. When folsom moves to milestone-proposed, his testing has to change and now pull milestone-proposed instead of master - although there is no technical signal to indicate this to him. Similarly, when it is released, stable/folsom is now the thing he would like to grab. If the opening of the folsom dev cycle had begun with the creation of a symbolic-ref to master, then further things interested in the thing called folsom could just follow that.

- Similar to debian, but opposite - in other cases one might want to pull "stable" - without specific knowledge of what the latest letter-based release might have been, and would like that to change whenever the latest stable thing is released.

Jeremy Stanley (fungi) wrote :

A symbolic ref is a local construct, relevant to and resolved within the copy of the repository where it is created. To outside consumers it appears as a separate branch, so as long as the intent is to pull from and push to the particular repository where that symbolic ref lives this should work fine. However, if it's of interest to have those symbolic ref names available from other copies of repositories, they'll have to be created there manually unless you have low-level control sufficient to duplicate git symbolic-ref commands at that end (for example gitolite grew a feature recently enabling project owners to be able to add these: ). I couldn't find any positive confirmation that github has a similar feature, so further exploration there is in order.

Also worrisome, based my interpretation of this thread repointing things other than HEAD is probably an off-label use from upstream Git's perspective:

Jeremy Stanley (fungi) wrote :

I've thrown together a rudimentary proof-of-concept implementation of your symbolic-ref idea ( ) and it seems to work as expected given the caveats above. I agree, however, with James E. Blair's concern that this will be either confusing or useless to downstream consumers since the reference is seen as a branch outside of the local copy on the Gerrit server. I'm also worried that zuul will act on changes it sees in these independently of the real branches they represent and, unless modified to ignore them explicitly by name, duplicate testing activities as a result.

In IRC he suggested constantly updating tags instead, so I've tested doing this with lightweight tags on my development Gerrit VM and it seems to fit the bill. A client can pull from a tag name instead of a branch name and will get the commit from the branch to which the tag refers, even if the tag has updated to point at a commit on a new branch since the last pull.

Given that there's at least one discussion proposed for ODS around reorganizing the branch structure and release branching process, further development on a solution should be postponed until we've got a clear picture of how things may change in that regard.

Jeremy Stanley (fungi) on 2012-10-22
summary: - use symbolic-ref from gerrit to provide moving codename targets
+ use lightweight tags on gerrit to provide moving codename targets
Jeremy Stanley (fungi) wrote :

The lightweight tag solution seemed to be acceptable to all discussion participants at the summit (bug retitled accordingly), so I'm coding up a new proof-of-concept using a post-merge hook to track the tip of arbitrary branches specified in a YAML file kept in openstack-ci-puppet. Once I have it confirmed working on my test Gerrit instance, I'll check in a patch to add it on for more collaborative testing.

Jeremy Stanley (fungi) wrote :

The change implements a prototype using tags, as described above. Comments welcome.

Jeremy Stanley (fungi) on 2013-04-23
Changed in openstack-ci:
importance: High → Wishlist
milestone: grizzly → none
Jeremy Stanley (fungi) wrote :

Switching to wishlist and removing milestone. The change linked above can serve as a reference implementation if there's any interest in putting it into production. It's tested out and works as designed with gerrit and replication, but there's some question around who updates the configuration mapping names to branches and how that's integrated into the release process (both from a tooling and a human procedure perspective).

Jeremy Stanley (fungi) on 2013-04-23
Changed in openstack-ci:
status: In Progress → Triaged
assignee: Jeremy Stanley (fungi) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers