tramlinehq / tramline Goto Github PK

Release page is currently a mess as there are too many conditions and SQL queries are being generated from there. It is due to missing abstractions and lack of clean-up.

• All apps with configured release train nested under Apps
• Under the trains, nest the active run

Currently, it shows the merge commit created by merging working branch into release branch.

We are currently creating an extra job on the workflow solely for storing the version_code and refer that once the workflow is finished.

This approach is having following drawbacks

1. Additional job
2. Artifact extraction is expensive
3. We get to link step_runs with workflow only after workflow run is finished
4. This approach is platform dependent.

Alternate approach is to have

1. An end point in tramline to receive workflow event
2. Create a http call from workflow as the first step with workflow details to this endpoint
3. This can be accomplished by our own cli or simple curl script

Advantages

1. Early feedback so that we can link step runs with workflow run(CI action) and show in the UI
2. No expensive processing in callback handler
3. Similar approach can be implemented in most of CI platforms

I have to click on "edit" step button to see those details.

For a release train where the version series is 17.2.*, the version number starts from 17.2.1. It should start from 17.2.0.

Title

[Release kickoff] vX.Y.?

Description

New release train (train name) triggered by user name.
The working branch branch has been merged into release branch branch, as per branching strategy name branching strategy.

The edit step buttons are disabled but I can still click "add another step".

Refer to the comments down below.

Currently, it crashes like this --

Bootstrap does have button class on links which makes anchor tags looks like buttons, that is common workaround, not sure if our theme have the something, alternatively we can just pass method: :get to button_tag which will make it a get request

Offending commit: f1b25a3

Thread: https://tramlinehq.slack.com/archives/C02U106LACX/p1659019319737099

• In the Steps section, say "you need to add at least one step to run this train"
• In the Releases section, say "no releases yet" instead of rendering an empty table

Keeps redirecting back to the train settings page.

This is the tag: https://github.com/tramlinehq/ueno/releases/tag/v17.2.1
The train that created it was following Almost Trunk and the tag should've been on the release branch.

• should only show up when play store is selected as a channel
• options should match the terms that play store itself uses
  • production
  • open testing
  • closed testing
  • internal testing

Currently, I have to fill out the email address again myself.

Via @tachyons on Slack -- https://tramlinehq.slack.com/archives/C02U106LACX/p1657102742227059

As per our current data modelling, each train can have multiple train runs (AKA releases) and steps. A step_run refers to the execution of train run for the given step for given commit. Ie there is no proper abstraction train run per step. This makes storing approval status complicated. Current workaround is to use sign_required column, but it is a clear smell of missing abstraction

We are currently processing webhooks in synchronous manner and return status to Github only after process is completed. This causes issues due to following reasons.

• Github is not interested in what we do with the payload or result, it only interested whether the payload received successfully or not
• Some payload handlers take time, sometimes several seconds, this causes webhook to timeout and retry
• When we process webhooks in synchronous manner, the number of requests we need to handle at the same time increases due to latency and causes bigger request queue.

IMO we need an easy way to debug a setup. For example, without running an actual release I cannot figure out if my webhooks and integrations are properly set up or not.

Aboo thinks that such a feature will be useful to validate values with connected integrations.

Branch name as breadcrumb will get confusing in some branching strategies, for ex parallel branches strategy. So let's change this for all branching strategies for consistency.

v33.4.? will look better instead of prod.

Users should be able to just trigger workflows and manage branches, but not use deployment channels controlled by Tramline. This is because they may have their own deployment configured in their CI workflow.

Only the CI workflow name is displayed.

Constraints

name

no constraint

description

no constraint

bundle identifier

• no release train should be running
  • because if it is, then the system will attempt to submit a build to the wrong play store account because the build identifier has changed
  • the submission will not go through and the system will start throwing errors

build number

• only allowed to increase the build number, not decrease it
• both play store and app store only allow builds with increasing "version numbers" anyway so this constraint makes sense

Approaches

Choosing commits

1. User marks a commit message
   ... and we automatically cherry pick that commit onto the release branch of the live release.

2. User picks commits from a list populated from the working branch
   ... and we cherry pick that commit onto the release branch

Direction of copy

1. Commit lands on release branch and is cherry picked onto the working branch

2. Commit lands on working branch and is cherry picked onto the release branch

Questions

• which one of the two approaches is simpler to implement? better for the user?
• how will failures be handled?

Notes

Handle stopping release with a warning if a diff exists between the release and working branch. Also, do the same for other branching strategies.

Currently we are just generating and sending notifications without any persistence. Having persistence feature makes sending notifications to multiple channels and showing notifications on the UI easy. noticed is a good gem which take care of most of the heavy lifting regarding the notifications

We need to make merging PRs sequential but non-blocking, as creating and merging PRS aren't straight forward when there are merge conflicts which need to be manually handled by developer. If there are multiple PRs we need to wait for the first PR to be merged before creating the second PR. We need to persist the state to handle this and can't be done inside a transaction.

This is currently only an issue in Parallel Branch & Back-merge strategy.

We are currently storing artifacts in zip as provided by GitHub action, this makes uploading to play store difficult and expensive. Also, since different CI providers might provide artificats in different formats, it is better to store in standardized format

When running mosaic-html, see http://localhost:8080/component-button.html

• show a link to the running workflow
• if possible, show status of the workflow like
  • waiting
  • running
  • success
  • failure

For now, it is okay if the status does not update in real time.

• For almost trunk strategy, show base commit (on the working branch) from which release branch was created
• For backmerging strategy, show base commit (on the working branch) from which release branch was created
• For parallel strategy, from the merge commit that was created, show child commit on the working branch