Refs in the gate repository

Tags

The gate repository holds tags that follow a certain naming conventions:

changes/NNN
This tag indicates the validated merge commit that was submitted by the user and built in the build # NNN.
builds/NNN
This tag indicates the commit that was actually built and tested in the build # NNN. This is the result of a merge between the then-tip of the upstream ref, and changes/NNN. (Therefore if this merge was a fast-forward, this tag points to the same commit as changes/NNN.)
validated-merge-for/UPSTREAM/YYYYMMDD-HHMMSS[.X]
The changes/NNN tags are more easily memorable but they are only available once the build has started. Therefore, when a proposed change is pushed to the gate repository, Jenkins assigns a tag that follows this longer format. The UPSTREAM portion refers to the upstream ref that this change is meant for (such as 'master', but this can include '/' in it, such as 'feature/foo'), and YYYYMMDD-HHMMSS is the timestamp of the submission. If multiple changes are pushed within the same second, the additional .X (where X is a number) is appended to create unique tags.

These tags are useful for developers to collaborate on changes that are being validated or rejected. For example, if a developer submitted a change and it was rejected, another developer can fetch the change, make an additional commit, then submit it to integrate that to the upstream.

Aside from these tags, the gate repository also contains any tags that are set in the upstream repository, as well as tags that are created in the Jenkins workspace. For example, the Git plugin add its own tag for every build.

Since the gate repository tends to host a large number of tags, you normally don’t want to fetch every single tag in it. To fetch a specific tag and that alone, run Git like git fetch -n tag changes/123 where '-n' prevents Git from fetching tags automatically and "tag changes/123" tells Git to retrieve the specific tag.

Branches

The gate repository also contains branches that map to the permalinks in the job in the form permalink/ID where ID refers to the identifier of the permalink, such as lastSuccessfulBuild or lastFailedBuild. Other plugins often define additional permalinks, for example the promoted builds plugin.

These tags can be useful beyond the validated merge use case. For example, when a build is promoted, you can start another job which checks out the branch that corresponds to the promotion and then deploys to the staging server.