Product Manager Approval needs to be provided in the table below for each version. Without Product Manager Approval, the Backport Request will not be taken into consideration by Release Managers
Version
Approval from Product (to confirm the bug justifies the upgrade cost)
Approval by Release Manager
Notes
17.0
16.11
16.10
16.9
16.8
16.7
16.6
16.5
16.4
16.3
16.2
16.1
16.0
Does this bug potentially result in data loss?
This change will not result in dataloss and is only a UI component that can be dismissed by the user.
Customer impact
On GitLab.com, we discovered that a large number of our customers were not prepared for the tokens to be expired. For self managed users we are using a multi-prong approach of sending communications via a variety of channels (emails/CSM outreach) but an in-app notofication that warns them about the risk and links to troubleshooting scripts has the best probability of being noticed.
@svistas@ifarkas will create and link backport MRs here for the additional versions we need to backport to. In parallel I'll work to get frontend coverage from devopsgovern in case we need FE specific input while Eduardo is away (including the option to disable the banner)
If there is none, would the group level callout work as a workaround? Alternatively the environment variable approach seems the easiest one to implement and configure.
@ifarkas Ideally yes, but the sheer number of backports that must be done is quite large for the first wave so I was going to leave that out until the rake task/banner/setting work is done (and users who closely upgrade to latest versions have already ran into the banner)
@svedova Could I request your help in adding the env var based check for the backports? We'd then work with Sofia to ensure they pass the pipelines. @eduardosanz will pick the remaining work next week (anything that's left over)
@adil.farrukh sure! I think @ifarkas will add the support in the backend first and then I can implement the frontend part. At least that was my understanding when I spoke to him.
@eduardosanz This is the issue I reached out about on slack (internal). @svedova Thank you for jumping on to help on short notice . Eduardo can now help continue the backport MRs forward
@eduardosanz Do the MRs above contain different changes than those already linked in the issue above? i.e I know they add env variables so perhaps we combine them or relink them in the issue above
@eduardosanz Since the migrations are also being reverted, we'd run the risk of some users upgrading to a GitLab version 16.0+ to see the banner but no expiration added, as the migrations introducing the expiration is also being reverted in the same patch.
In addition to the option for admins disabling the banner if needed, we would also want to only show it if the original migration adding the expiration ever ran for this user in the first place. Can we add the conditional for that?
Stan suggeste originally in https://gitlab.com/gitlab-org/gitlab/-/issues/462157#note_1977747019 i.e Check if CleanupPersonalAccessTokensWithNilExpiresAt is part of the batched migrations for this instance. This would need to be added for the current set of backports but also the one we did last time.
Does it make sense to extend the MRs in this issue to cover 16.0-17.0? such that we add the migration based check and the option to disable the banner for 16.6 to 17.0 as well? We can request backend help for that if needed
I believe we are very close to merge in master the MR that checks if CleanupPersonalAccessTokensWithNilExpiresAt migration has run, and display the banner conditionally. It is going through the second round of reviews. If this MR gets merge today or tomorrow, it would be ideal.
I have updated all the MRs in the series to match the master branch, so every branch should be consistent with master.
If I am not wrong, 16.6-17.0 should not be a problem to approve. All the QA tests should pass there.
@eduardosanz thank you! Looking at the MRs, I see we have requested SET approvals on failing specs. Once ready, please setup maintainer approvals for the MRs (& SET if needed) so that they can be made ready from draft.
Before midweek (17th), we should have the checklist in Ensure banner backports are completed (gitlab-org/gitlab#471161 - closed) and possibly reviewed by release team to make sure none of the steps are missing that'd prevent them from merging the backports on 19th (& let me know if I can help coordinate any of those).
@hsutor More so a process item, but if we could have your approval on the above table for GitLab versions?
In the interest of time, I suggest for now we may need to be ready to punt on making every GitLab QA test pass since it will take some work to backport all the relevant changes. However, I'm certainly willing to try to make as much progress as we can.
Thanks @eduardosanz! A quick question regarding the link to the token troubleshooting doc: I see in the backports it still points to gitlab.com. Are we planning to update it in these backports, or in a separate set of MRs?
@ifarkas, my understanding is that we are going to keep the link to token troubleshooting doc in gitlab.com, as this section has been updated recently. If we decide to update the link and backport the troubleshooting section we will do it in a separate MR.
@eduardosanz@ifarkas From our chat yesterday, the preferred path is to link it to the troubleshooting pages for the instance. We will however need to backport them and link the relative versions. It'd also mean we can't direct them to the latest version of the scripts.
Given that the banner backported for 16.5+ already points to .com docs, we may not have a lot ROI to try point to SM specific troubleshooting (& ensure that's ready in time for 19th) now and I'd suggest we keep it as-is. I am also open to input from Stan or others if you think that's a significant issue worth correcting.
@svistas and @richard.chong all the MR have maintainer approval. Would you mind taking a look at these and approve if ready? I would suggest taking out of draft status and marking them as ready on the table description. Thank you very much!
Adil Farrukhchanged title from Draft: Backport UI banner for SM managed users informing them about token expiration to Backport UI banner for SM managed users informing them about token expiration
changed title from Draft: Backport UI banner for SM managed users informing them about token expiration to Backport UI banner for SM managed users informing them about token expiration