When switching branches in the pipeline editor, the pipeline status at the top shows the latest pipeline for the default branch instead of the non-default branch the user switched to.
This is an interesting issue, which brings me to the question of what are the user expectations when they see the pipeline status? Is it the latest pipeline for the branch they're in, or the latest pipeline for the default branch? I just wanted to make sure we're all in agreement on what the expected behavior should be.
I'm also wondering if we need to be more specific about the information shown here, although maybe this is already a convention that's universally agreed upon in other pages in GitLab that show the latest pipeline. Looping in @nadia_sotnikova@dhershkovitch
As for the cause of the behavior itself: the query for getting the pipeline status doesn't include the branch so it probably defaults to getting the latest pipeline for the default branch. It's vague to me as well tbh, so maybe @lauraMon can confirm what's happening on the backend?
My personal expectation would be that the pipeline would be the latest on the branch...
This is the way it works today in the single file editor and I believe we should follow the same pattern, pipeline status should be context related, so if I switch between different branches I should see the latest for the selected branch
After looking into it some more, it looks like the query might not be the problem. The frontend was just not updating commitSha when we switch branches, which is what the query uses as reference to which pipeline it should fetch. When we create a new commit, this value is updated and we see the pipeline status update accordingly as well.
The expected behavior is that the frontend should get the latest commitSha every time we load a new branch. This should automatically update the pipeline status.
@lauraMon is there an existing graphql query that frontend can use to get the latest commitSha of a project given a specific branch?
Bear in mind that sometimes the pipeline status might not change if there's no new pipeline triggered for those branches. For example, my test branches are all copies of each other with no real changes between them (created a bunch of them before to test the pagination/infinite scroll for the branch selector).