Sam Beckhamchanged title from Add the branch switcher to the pipeline editor to Create a GraphQL resolver that returns a list of available branches for a project
changed title from Add the branch switcher to the pipeline editor to Create a GraphQL resolver that returns a list of available branches for a project
Sam Beckhamchanged the descriptionCompare with previous version
changed the description
Sam Beckhamchanged title from Create a GraphQL resolver that returns a list of available branches for a project to Add the branch switcher to the pipeline editor
changed title from Create a GraphQL resolver that returns a list of available branches for a project to Add the branch switcher to the pipeline editor
@dhershkovitch@nadia_sotnikova If the user selects a different branch, say develop and works there. If they refresh the page, is it important that we keep them on that branch or can we just reset it to the defaultBranch? If we want to retain which branch the user was on, it's not that complex but it does add some work. If we don't mind (at least for this iteration) then by default, refreshing would set you back to the main branch unless you were redirected from the repository view because of #321652 (closed) where a query param will set the default branch. Is that acceptable?
Implementation wise, couple of notes:
The dropdown should be a dumb component and render the list of branches
I think we can leverage Apollo local cache to set the currentBranch
If there is a query param, we use that as a default value
When a user select a new branch, we set the cache with new currentBranch
We can get that value in the commit form with a client getter
After we update the branch, we can call a refetch on the getBlobContent query, which should also trigger a refetch on ciLint
@f_caplette, that's not an ideal user expirence, but something we can release if we document and open a follow up issue to fix it on the next iteration
@nadia_sotnikova Yes the user would lose their progress, but that's actually a separate issue. Even if we remembered the branch when refreshing, you would still lose your progress on refresh. That's something we can look to in another issue because it requires using the browser local storage to keep the user current progress, which we don't do at all currently.
The backend is also at risk since there's significant scalability issues with loading all of the branch names into memory. There's ~19K branches in the main gitlab repo for repeference.
FYI I will be breaking up the frontend implementation for this in several MRs so it will be easier to ship and review. The breakdown of the implementation for this issue is as follows:
!57562 (merged) Add dropdown UI to the pipeline editor (no functionality yet; will use a client resolver for now)
!57941 (merged) When clicking on a branch, switch to that branch and load the correct data
!59217 (merged) Remove client resolver and fetch the branch list from GraphQL (when backend is ready)
[-] Add branch switcher to empty state (will be addressed in #327673 (closed))
This will be under the :pipeline-editor-branch-switcher feature flag while in development.
Thanks for the update @mgandres I assume this one will miss %13.11 as we'll also need to roll out the feature flag changes. Should we mark this one as at risk?
For the MVP, the core functionality has been merged and the last missing piece is !59217 (merged) which integrates the backend query to load the available branches and allow the user to search for a specific branch. I created a draft MR which already does all of this, but we're currently in discussion on how to handle loading all branches for large projects, so it's still in WIP status.
In the meantime, while that's being resolved, I'll also be doing these branch switcher follow-ups now:
Update: I'm going to put this at risk because there's an additional backend update to the query that's needed to handle loading branches for large projects. It's already in review. Once that's done, I can update the frontend again -- I'm hopeful it will get done next week, but it's very likely that this feature will slip and we won't be able to enable the feature flag by the end of the milestone.
On the bright side, the follow up issues (adding the branch switcher to the empty state, retaining same branch on refresh) are done or already being reviewed. So when we do flip the feature flag on, those changes will be included as well!