It's very convenient having the ability to create, view, and comment on issues from within vscode.
I understand there are a few open issues related to pipelines jobs that I'd assume would be tied into this solution. But I didn't see an open issue specifically requesting this feature, although #97 (closed) may actually be good enough honestly, if it would work like issues/MRs do.
Proposal
Curious if embedding /-/pipelines/$Pipeline_ID would be an option, similar to what the experience is when clicking an issue and how we can "View issue and MR details and comments in VS Code"? This would at least allow us to see which job failed, if nothing else.
Further details
It looks like @fatihacet did some work towards integrating jobs under pipelines in For Current Branch section of the sidebar and that's great!...not sure if that work/code transferred over with the project ownership shift. I'm not sure if the intent was clicking one of those jobs would have opened the build output?...that's what I would love to see!
Rather than clicking off to the browser it would be very helpful if pipelines could also be embedded and interactive/clickable within vscode without being sent off to the browser. What currently exists within the status bar and left panel is helpful. What @fatihacet was working on would have been even better but I think working it in the same way as issues/MRs in combination with the other efforts would be great as well.
Tomas Vikchanged title from Add the ability to show pipelines within vscode, like issues/MRs, rather than opening up in the browser to Add the ability to show pipelines within vscode
changed title from Add the ability to show pipelines within vscode, like issues/MRs, rather than opening up in the browser to Add the ability to show pipelines within vscode
Tomas Vikchanged the descriptionCompare with previous version
@phikai@pedroms I've been thinking about this a lot recently and I think that this would be an "easy win" to better surface our CI/CD status in the extension.
@viktomas Is the proposal here just that we'd be able to view the jobs not that you'd be able to interact with each of the icons and start/stop jobs (which is almost a dupe of #97 (closed))?
I sort of understand the premise of this issue, but I wonder how valuable interacting with these items is in the editor vs. the feedback some of these things provide.
Is the proposal here just that we'd be able to view the jobs not that you'd be able to interact with each of the icons and start/stop jobs
@phikai Yes, my idea was to do the pipeline presentation as a first iteration. It will already provide better feedback (e.g. oh, linting failed, I'll just rerun npm run lint locally to find out what's wrong). And the interactivity will be then built on top of this presentation.
@v_mishra as this involves showing pipelines in the context of our VS Code extension, could you please take a look at the description to see if anything catches your eye? It would also be great if you could review the MR once @viktomas marks it as ready for review (FYI, Tomas usually shares comprehensive videos that showcase the functionality, making it much easier to review).
The only thing I'm unsure of is if we can get the pipeline/job status icons and colors to mimic the ones we have in GitLab.
Other than that, everything looks reasonable to me.
The only thing I'm unsure of is if we can get the pipeline/job status icons and colors to mimic the ones we have in GitLab.
AFAIK, we can only use the default icons (Overview, Reference). It is possible to override these with a custom Product icon theme but that would change the icons everywhere in the user's VS Code, not just in the GitLab extension. (this feature is meant for new themes like Fluent Icons).
Regarding colors, it might be better to stay within the VS Code color theme (so all colors look consistent) Reference. Looking at the interface, it doesn't allow us to use custom RGB defined colors.
as this involves showing pipelines in the context of our VS Code extension, could you please take a look at the description to see if anything catches your eye?
AFAIK, we can only use the default icons (Overview, Reference). It is possible to override these with a custom Product icon theme but that would change the icons everywhere in the user's VS Code, not just in the GitLab extension. (this feature is meant for new themes like Fluent Icons).
Regarding colors, it might be better to stay within the VS Code color theme (so all colors look consistent) Reference. Looking at the interface, it doesn't allow us to use custom RGB defined colors.
This sounds good for an MVC approach. I couldn't think of a better first implementation with the stated limitations
@viktomas a couple of things, we're now trying to show linked pipelines in the minigraph, something you'd like to incorporate on the VS Code side as well?
And in the case of DAG, would the jobs appear as one long list organised by execution sequence?
@nadia_sotnikova since this concerns visual representation of pipelines, this would need your input too.
@viktomas a couple of things, we're now trying to show linked pipelines in the minigraph, something you'd like to incorporate on the VS Code side as well? And in the case of DAG, would the jobs appear as one long list organised by execution sequence?
@v_mishra That looks really cool it is not something I'd be able to do in the MVC, but we can create an issue for it. I might need guidance for where can I retrieve the linked pipelines from the REST API.
And in the case of DAG, would the jobs appear as one long list organised by execution sequence?
I'm not sure. The sidebar supports tree structures, not graphs. Quick idea: we could create "fake" stages (downstream pipelines, upstream pipelines) similar to test and package in the issue description. Expanding these "fake" stages would show all downstream/upstream pipelines sorted by created_date.
I roughly finished the exploratory part of the implementation, now I'm going to polish the code and write more tests. I would like to show a few aspects of the implementation to get feedback.
Amount of detail
I can show as little or as much information as we wish. The three "information levels" I can think of are:
basic
status explanation
status and time
The little grey text (e.g. "Prepaparing · 14 days ago") is called description. We can use arbitrary text.
The statuses "Preparing" and "Waiting for resource" only apply to pipelines, but the way I mocked them, they show up for jobs in the mocks. They won't be showing for jobs in production, because jobs don't use those statuses.
We would also always show the full detail in a tooltip on hover:
Icons and colours
I tried to find best-fitting icons from available icons and I tried to match the base colours with GitLab (i.e. blue status is still blue).
The only allowed animation is "spin". This is how it would look like with "sync" icon:
Display logic
I'm thinking that we would by default collapse succeeded pipelines. That would allow us to save many API requests and I think that when pipeline succeeded, I don't need to know all the jobs by default.
I'm not sure how to sort the stages, so far I just take the jobs as they come from API and in that order I create a list of stages.
The stage takes the "most severe" status from it's jobs, in order of importance:
This is amazing, thanks so much for working on this! @viktomas This would really help with context switching when monitoring your pipeline run.
Your proposal looks like a great MVC to me!
I tried to find best-fitting icons from available icons and I tried to match the base colours with GitLab (i.e. blue status is still blue).
We have a set of pipeline status icons to use for the job and pipeline status, can we use those instead of the VSCode icons? You can search our SVG Icons library to find the right icon for each status.
The only allowed animation is "spin". This is how it would look like with "sync" icon:
Animation could be good for the running job, but our status icons weren't made with animation in mind. Maybe we can skip animation for now if possible to keep it simple?
The little grey text (e.g. "Prepaparing · 14 days ago") is called description. We can use arbitrary text.
The statuses "Preparing" and "Waiting for resource" only apply to pipelines, but the way I mocked them, they show up for jobs in the mocks. They won't be showing for jobs in production, because jobs don't use those statuses.
We would also always show the full detail in a tooltip on hover:
The status description should match the job/ pipeline status directly, so the status we show for that job or pipeline in GitLab is the same.
But I'd put both status text and timestamp into the tooltip because the most important information is the job name and the status icon. GitLab CI users are very familiar with the status icons we have in the pipeline graph in the pipeline details page, so it should be enough.
Question, are the jobs clickable to click thru to the job detail page?
@dhershkovitch Check this out, this is directly related to the epic for extending pipeline authoring tools to local editors. We should look into further ways the VSCode extension can be improved and made discoverable for our users. This is super useful.
We have a set of pipeline status icons to use for the job and pipeline status, can we use those instead of the VSCode icons? You can search our SVG Icons library to find the right icon for each status.
But we lose the ability to set colour in the code (we'll have to set colour in the SVGs directly) and we'll need to provide two sets of SVGs: for the light theme and for the dark theme. The SVGs that you linked are only light-theme friendly (because they hardcode white background in many cases) (and even then they would have to get coloured in the SVG markup).
light theme
dark theme
I think that editing the SVG colours to match VS Code default dark and light colour themes might be too much effort. So I suggest that in the first iteration we picked the best fitting icons from the default icon theme (Overview, Reference) and we'll add the fully styled icons in the next iteration.
Question, are the jobs clickable to click thru to the job detail page?
I can implement them as clickable. The click would open the job in the browser.
This is awesome @viktomas thanks for working on it, clickable jobs to the job detail page is a great idea.
One question, once this will be available is there a way for us to track usage? e.g. how many users are using the extension?
I think that editing the SVG colours to match VS Code default dark and light colour themes might be too much effort. So I suggest that in the first iteration we picked the best fitting icons from the default icon theme (Overview, Reference) and we'll add the fully styled icons in the next iteration.
Yes, I agree, let's not block this iteration because of the icons, it can provide a lot of value to many developers as is.
Maybe we can try to make the existing icon colors more similar to the corresponding icon color in GitLab UI. We can replace the black color with white for the sake of the VSCode dark UI.
running can be blue
created can be light gray
failed can be red
warning can be yellow
success can be green
canceled can be white
pending can be yellow
skipped can be light gray
What do you think?
I see some job states I was not aware of before! I don't think I've ever seen them in the pipeline graph. Do we show these states there?
waiting for resource
preparing
They both seem super useful, I just want to make sure we show them similar to how we show them in the GitLab UI, if they exist in the UI.
Question, are the jobs clickable to click thru to the job detail page?
I can implement them as clickable. The click would open the job in the browser.
That would be great if the Pipeline ID was clickable and took you to the pipeline, and the jobs would link to the job page. It would provide a very easy access to the pipeline graph the job logs.
@nadia_sotnikova The MR has been reviewed and released, but I'm happy to do any small follow up changes this week.
That would be great if the Pipeline ID was clickable and took you to the pipeline, and the jobs would link to the job page. It would provide a very easy access to the pipeline graph the job logs.
Both pipeline and job items are clickable, and they open the job in the browser:
Maybe we can try to make the existing icon colors more similar to the corresponding icon color in GitLab UI. We can replace the black color with white for the sake of the VSCode dark UI.
Do you know if we can automatically generate SVGs with different colours? Otherwise changing the colour would be on-off manual work which would have to be repeated every time we change the SVG icons.
I see some job states I was not aware of before! I don't think I've ever seen them in the pipeline graph. Do we show these states there?
waiting for resource
preparing
I think those are only for pipelines (I took the statuses from our API Documentation)
I mentioned it under the screenshots, but the way how I showcased the statuses was a bit confusing. It was the easiest way to show all statuses in one screenshot
The statuses "Preparing" and "Waiting for resource" only apply to pipelines, but the way I mocked them, they show up for jobs in the mocks. They won't be showing for jobs in production, because jobs don't use those statuses.
I meant VSCode icons, so the icons in VSCode are the same color as the corresponding status icons in GitLab, which would make it easier to quickly read status. Doesn't necessarily have to be exactly the same color, just close enough.
So in VSCode the status icons would have these colors:
running can be blue
created can be light gray
failed can be red
warning can be yellow
success can be green
canceled can be white
pending can be yellow
skipped can be light gray
Do you know if we can automatically generate SVGs with different colours? Otherwise changing the colour would be on-off manual work which would have to be repeated every time we change the SVG icons.
Pretty sure we don't automatically generate SVGs with different colors, it's a problem in GitLab's dark mode. There's been discussions around it, but it's not being prioritized right now. Here's a related Slack thread. The Foundations UX team is planning to look into this in Q3.
I did find a solution to the hardcoded background problem. Turns out that currently in GitLab UI we mostly use the borderless variant of the pipeline status icons which don't have any background. The border is then applied around the SVG. https://gitlab-org.gitlab.io/gitlab-svgs/?q=border
I did find a solution to the hardcoded background problem. Turns out that currently in GitLab UI we mostly use the borderless variant of the pipeline status icons which don't have any background. The border is then applied around the SVG. https://gitlab-org.gitlab.io/gitlab-svgs/?q=border
@nadia_sotnikova That's cool, that should make it easier to automatically change the color However, I don't think we can use the SVGs even without white background because the black main stroke color wouldn't work in dark (default) mode.
I created MR to change icon colors to your specs !325 (merged)
Hey @viktomas - I did a bulk update an hour ago, as there is a new label introduced - add the workflowcomplete label. It seems like you got automatically unassigned It was unexpected from my side as well, so please give me some time if it was expected behavior. Sorry about that!