2045812 - Add an API endpoint for Lando uplift train selection guidance

Status: RESOLVED FIXED

(Websites :: whattrainisitnow.com, enhancement, P3)

Description

[Connor Sheehan [:sheehan]]

See bug 2044143 comment 2 for more context.

We need a new API endpoint in whattrainisitnow.com that provides the data required for two changes in the Lando train selection:

• A new widget to select the target release version for the uplift to land on, which will then resolve to a suggested train. For example, the user would say "I want to uplift to v152", which would then suggest beta or release depending on the timing in the release cycle.
• A helpful hint for which release their uplift will land in when selecting a specific train. For example, selecting firefox-beta will display a message like "This will land in Firefox v152", or "This will land in Firefox v153" depending on timing in the cycle.

Lando's front-end will send an API request to whattrainisitnow.com and hold the response in the browser, which will then be used to guide the user in selecting the appropriate uplift target.

Comment 1

[Pascal Chevrel (relman team) -> :pascalc]

I created this api locally:

{
   "nightly":{
      "version":153,
      "release_date":"2026-07-21"
   },
   "beta":{
      "version":152,
      "release_date":"2026-06-16",
      "has_betas_left":true,
      "is_rc_shipped":false
   },
   "release":{
      "version":151,
      "release_date":"2026-05-19"
   }
}

I think the extra fields in the beta section should be enough to create your widget.

The has_betas_left boolean will tell you if we have shipped all of our betas.
The is_rc_shipped boolean will tell you if we have shipped our Release Candidate

has_betas_left = true => uplift targets the beta branch
has_betas_left = false => uplift targets the release branch
has_betas_left = false + is_rc_shipped = false => uplift targets the release branch and should be in the major 152.0 release
has_betas_left = false + is_rc_shipped = true => uplift targets the release branch and should be in a 152.0.x minor release

If the uplift is for a patch on main (nightly 153 here) and the target requested is release 151, then we should propose to uplift to both beta and release branches.

Would that work for you Connor? I can put that endpoint on production if you want to play with it.

Note that at the end of the cycle, for the last beta and the rc there will be a few hours gap where this will be slightly off, that is when we are building the last beta and the last RC but haven't shipped it yet. At this point the api would not reflect the fact that uplifts are no longer open for last beta or rc as we are building it. I think it should be OK in practice but we could shorten this window of uncertainty for at least beta if we see that we have confusion.

Comment 2

[Pascal Chevrel (relman team) -> :pascalc]

I put the branch on a demo server so you can play with it: https://fx-trains.herokuapp.com/api/lando/uplift/train/

Comment 3

[Connor Sheehan [:sheehan]]

This looks great! I will start working on the implementation using the demo server.

Just to clarify the logic, if Lando received the response in comment 1 from the server:

The version selection widget would display v151 and v152 as possible choices for uplift, pulled from the API response. No need to suggest v153, as that would be a regular landing to autoland.

• If the dev chooses v151 -> uplift should target release and beta.
• If the dev chooses v152:
  • has_betas_left == true (beta-shipping) -> uplift should target beta
  • has_betas_left == false and is_rc_shipped == false (RC-shipping) -> uplift should target release, with a note it lands in major v152.0
  • has_betas_left == false and is_rc_shipped == true (dot-releases-only) -> uplift should target release, with a note it lands in minor v152.0.x

On the flip side, when the user chooses to manually select uplift trains:

• Selecting beta:
  • when beta-shipping, hint "This will land in v152"
  • when RC-shipping or dot-releases-only, present a warning like "No betas remaining for v152, select release to land this in v152".
• Selecting release:
  • when beta-shipping, hint "this will land in the next 151 dot release".
  • when RC-shipping, hint "This will land in v152.0 (major release)".
  • when dot-releases-only, hint "This will land in the next 152 dot release".

Assuming this is all correct I think we are good to ship this, we can make tweaks as required in follow-ups.

Comment 4

[Pascal Chevrel (relman team) -> :pascalc]

(In reply to Connor Sheehan [:sheehan] from comment #3)

This looks great! I will start working on the implementation using the demo server.

Just to clarify the logic, if Lando received the response in comment 1 from the server:

The version selection widget would display v151 and v152 as possible choices for uplift, pulled from the API response. No need to suggest v153, as that would be a regular landing to autoland.

Yes, I put the 3 steps of the train here (nightly, beta, release) for consistency, but you probably don't need to worry about nightly.

• If the dev chooses v151 -> uplift should target release and beta.

Note that it depends on if the patch is uplifted from nightly or beta. If the uplift is from a patch that is already on beta, either because it was already uplifted there or because it landed during the nightly cycle, only release should be proposed as a target. What is important for us is that if we uplift a patch from nightly, it shouldn't do nightly->release, but nightly->beta->release otherwise the bug would reappear in production a cycle later when beta becomes release.

• If the dev chooses v152:
  • has_betas_left == true (beta-shipping) -> uplift should target beta
  • has_betas_left == false and is_rc_shipped == false (RC-shipping) -> uplift should target release, with a note it lands in major v152.0
  • has_betas_left == false and is_rc_shipped == true (dot-releases-only) -> uplift should target release, with a note it lands in minor v152.0.x

On the flip side, when the user chooses to manually select uplift trains:

• Selecting beta:
  • when beta-shipping, hint "This will land in v152"
  • when RC-shipping or dot-releases-only, present a warning like "No betas remaining for v152, select release to land this in v152".
• Selecting release:
  • when beta-shipping, hint "this will land in the next 151 dot release".
  • when RC-shipping, hint "This will land in v152.0 (major release)".
  • when dot-releases-only, hint "This will land in the next 152 dot release".

Assuming this is all correct I think we are good to ship this, we can make tweaks as required in follow-ups.

Yes, that is correct, with the constraint that we don't want patches to skip a train with a direct uplift from nightly to release.

Comment 5

[Connor Sheehan [:sheehan]]

I've posted a PR for review in bug 2044143 using the new endpoint. Pascal, could you share the URL of the production endpoint for me?

Comment 6

[Pascal Chevrel (relman team) -> :pascalc]

(In reply to Connor Sheehan [:sheehan] from comment #5)

I've posted a PR for review in bug 2044143 using the new endpoint. Pascal, could you share the URL of the production endpoint for me?

That will be https://whattrainisitnow.com/api/lando/uplift/train/
(only the domain changes)

If you are happy with the API, I could merge the branch and push it to production so you could test with the real site

Comment 7

[Connor Sheehan [:sheehan]]

(In reply to Pascal Chevrel (relman team) -> :pascalc from comment #6)

(In reply to Connor Sheehan [:sheehan] from comment #5)

I've posted a PR for review in bug 2044143 using the new endpoint. Pascal, could you share the URL of the production endpoint for me?

That will be https://whattrainisitnow.com/api/lando/uplift/train/
(only the domain changes)

If you are happy with the API, I could merge the branch and push it to production so you could test with the real site

Yes please, let's ship it. :)

Thank you!

Comment 8

[Pascal Chevrel (relman team) -> :pascalc]

Attachment: fix

Comment 9

[Pascal Chevrel (relman team) -> :pascalc]

https://whattrainisitnow.com/api/lando/uplift/train/ is live

We can have follow up fixes if we find issues.