Support proper trunk flow

[kitallis]

Context

Almost Trunk

Currently, Tramline supports a few branching strategies. The primary one we recommend to our users is Almost Trunk. In this, when a user prepares a new release for a train with a working branch, say, main, Tramline does the following:

1. Cuts a new release branch in the pattern r/train-name/2024-10-13 from main where the date part is the date on which the release starts.
2. Finds the reference to the last finished release to that train, usually a tag or the sha of the last commit of the release. Computes the changeset between the last finished release ref and the current HEAD of the working branch.

As the release progresses, users land any fixes they need to make on the release branch and Tramline merges those changes back to the working branch (either when the release finishes or as they land depending on the configuration).

As new changes land on the release branch, Tramline triggers the relevant workflows to build the app.

At the end of the release, Tramline does the following:

1. Ensure all changes on the release branch are merged back to the working branch.
2. Cut a tag for the release to identify the exact commit sent for the release as it finished.

Trunk

(read more about Trunk Based Development)

How Proper Trunk (or just Trunk) flow should work in Tramline:

When release starts,

1. Tag the current HEAD of the working branch and use that tag to kick off the release flow (workflow, submissions, and so on). The tag could just be v1.2.0 where 1.2.0 is the next version name.
2. Listen to the working branch commits, save and list all the changes happening on the working branch in the Change Queue which can be "Applied" to the release (commits after the release tag was cut).
3. A user can apply HEAD, HEAD~1, HEAD~n off the list of the commits that have landed on the working branch since the last tag cut. Or they can apply all the commits in the change queue.
4. When the user applies a commit from the change queue, tag the applied commit with a patch version change on the release. So if the current version is 1.2.0, the last commit applied will make it 1.2.1.
5. As there are no changes to merge back since it is trunk-based, there is nothing do in post-release.

In summary,

• Apply commit → cut a tag
• No release branch, no auto-application of changes landing on the working branch

Simplified illustration of what should happen:

Requirements

• New branching strategy available to the user with the above describe mechanism
• Changes in the UI to not show a release branch
• Changes in the notifications to not show a release branch

Edge cases

• Disallow users from starting another release from the HEAD if the HEAD is already applied in the current running release
• If a commit in a change queue is unapplied and a new release has started above it, the change queue should be locked
• Hotfixes should be disabled for Trunk (for now)

Acceptance Criteria

• Interface to select new branching strategy
• Appropriate interface changes to respect Trunk
• Model validations
• Unit tests

Additional Notes

There is no hotfix flow in Trunk mode for the moment as a hotfix will either be the same release or a new release altogether. There are no finalize / post-release steps to be taken care of either like: cutting a final tag or making a PR. The only thing to do at the end of the release is to update DevOps charts.

[gitstart-connector]

Issue synced into GitStart. Please review, edit and hand it off to GitStart by following this link.

[gitstart-connector]

This issue has been handed off to GitStart: https://clients.gitstart.com/tramline/11653/tickets/TRAB-548