Filters for pipelines

Seeing how Issues does it, I see we already have a pattern for this.

So we could just add the filter and sort row. Start with just filtering on the person who triggered the pipeline. If it's easy, then filtering on any committer/commenter would be a bonus (I think). Changing the sort doesn't feel as important, but I could see someone wanting to sort by duration to look for really long builds (to try to improve them), etc.

Added ~19492 label

@jschatz1 This seems like a relatively simple UX change. Can someone pick this up?

@markpundsack I think this is not easy at backed at the moment. We should probably verify the backend work that is needed to have this feature.

@DouweM Is this doable?

@JobV View?

@jschatz1 It's doable if we start tracking who created a Pipeline. Which is easy to add. I can help with that.

This is certainly a direction issue. Let's schedule this tentatively for 8.10.

Added ~122770 label

Milestone changed to %8.10

mentioned in issue #3235 (moved)

@jschatz1 filter(s) make(s) sense!

Added ~15078 label

mentioned in issue #14127 (closed)

mentioned in merge request !4605 (merged)

mentioned in issue #18920 (closed)

mentioned in issue #18992 (closed)

Changed title: My Pipelines → My Pipelines => Filter for pipelines

@markpundsack consider updating the title and description to the filter situation

Changed title: My Pipelines => Filter for pipelines → Filters for pipelines + Global Pipelines List

Milestone changed to %8.11

I don't think anyone is working on this for 8.10. Moving to 8.11.

There might be an opportunity to replace the admin view of builds/pipelines with this global view.

mentioned in issue #19694 (closed)

mentioned in merge request !5272 (merged)

mentioned in commit f1083ba1

mentioned in issue #19982 (closed)

Changed title: Filters for pipelines + Global Pipelines List → Global Pipelines List + Filters for pipelines

Added ~307502 label

Milestone changed to %8.12

mentioned in issue #21277 (closed)

mentioned in issue #21725 (closed)

@markpundsack

commenter

You cannot comment on a pipeline for now.. the same as you cannot subscribe to one...

should we introduce a "starring feature" where you can star/subscribe to one? if so I think we should seriously reconsider the whole "subscribed" system for issues/mr/pipelines/commits etc.. make it more stable, make it searchable throughout the whole system etc.

Filtering for current pipeline tab within a project:

as for personal pipelines view/link, this should get its own link in the sidebar:

and its own cross-project view like the issues view:

As pipeline can become many, many, I would keep the pagination and set a ultimate amount of per page viewable per project ;) :

all these mockups are btw done inside the browser with interface elements already there ;)

let me know what you think

You cannot comment on a pipeline for now.. the same as you cannot subscribe to one...

@dimitrieh Yes, I meant the underlying merge request. Today, pipelines aren't tied to merge requests, but semantically, they are for me, as a user. So when I comment on a merge request (or otherwise subscribe to it), I'm saying I care about this MR. I might, therefore, want to see how it's pipeline is doing, including if it's green and whether it's been deployed to staging/production yet.

BTW, since originally writing this, I've come to believe that subscribed is the attribute I want. At least when referring to things "I" care about. I may also want to look for pipelines related to merge requests that developer X has touched, and I'd want some broad definition for that, better than just "author" or "assignee".

should we introduce a "starring feature" where you can star/subscribe to one?

No. :)

Mockups look good. I'm not sure how you want to handle the global list when there are multiple projects involved. It looks like you're grouping pipelines by project, but perhaps project should just be another column.

Related, once we add a project column to the view, we're one step closer to killing the admin view of builds (evolution of #19694 (closed)).

For the record, we cut scope of handling subscribed, contributor, and commenter. Triggered by would be the most important filter, although perhaps we should filter by project too...

or maybe filter by state, so we can find failed builds easily, or pending builds so we can cancel them all...

@markpundsack

got ya on the subscribe thing for MR, however a pipeline can also belong to a commit alone.. how would you subscribe to that? if it isn't you who authored it or triggered it?

project should just be another column

This would again increase horizontal space and wouldn't be inline with issues (which won't be a problem if see: https://gitlab.com/gitlab-org/gitlab-ce/issues/21660#note_14880834) , but I think you got a point. I would rather see all pipelines from all projects in the way they are triggered or last updated. A solution to this would however lie in adjusting the "stages" columns:

isn't it correct that: currently changes based upon which pipeline is on top? Which makes these columns information value either wrong or very low. it doesn't say much at the moment as some pipeline below may have 7 stages, which are all named totally different..

I think you don't even care "too much" how your "stage" is named, you just want to know which "part" of your pipeline has failed... or maybe even better yet, where it failed within that stage or how many builds of that stage are failed.. or which one build took the longest compared to the rest? all in one glance, so can dive deeper only if needed.

lets look at a more conservative new approach:

and finally lets take a look at a version that gives way more information, while still having less space occupied.

hovering a build will create a tooltip and will click you right through to build or stage
tooltip can holds information such as buildname, stagename, total run time

references from Circle CI and soundcloud ;)

See all the whitespace, thats now usable for other columns?

For the record, we cut scope of handling subscribed, contributor, and commenter. Triggered by would be the most important filter, although perhaps we should filter by project too...

I do not entirely get what you mean here, but do agree that if we take the approach of a project columns, sorting per project on global pipelines should become a thing. I think you mean to say you want this:

with an extra "scope" dropdown, which can be filtered with subscribed, contributor, and commenter.

mentioned in issue #19991 (closed)

got ya on the subscribe thing for MR, however a pipeline can also belong to a commit alone.. how would you subscribe to that? if it isn't you who authored it or triggered it?

@dimitrieh I'm not really following you. Or at least I don't think this is necessary. If there's a commit floating out there, without an associated issue or merge request, then yeah, I'm not going to see it. But then again, how would you possibly know that I'm interested in it? Finding it and subscribing to it sounds kinda silly. :) It's not the kind of thing you "follow".

@dimitrieh Great mockups! I really like the first one. I was going to suggest just dropping the stage information altogether when looking at the global pipeline view. But what you propose does add value so you can quickly see how far something got, and presumably hover over a stage to see what stage it was, and which jobs failed.

Alternatively, we could just state the information with text. Such as listing where it failed, if it did. Or listing what the final stage was, if it all succeeded. The reason I think listing the final stage is interesting is because the same project can have different pipelines for different triggers, such as master might deploy to staging, but another branch does not, so highlighting that this pipeline made it to staging, production, etc. is useful. Also, manual actions can extend the pipeline even further, so knowing that someone manually triggered the continuation is nice. Again, your mockup probably does a better job at this.

I don't think I'm fan of the bar graph for this view.

I'm not sure how best to filter the global pipeline view. Let's start with the simplest stuff, such as author and triggered by. State would be reasonable. Subscribed might be a checkbox. A dropdown for project might make sense although that kinda gets weird, because why didn't you just go to the project then. But maybe it'll be easier to go there. Or maybe you're looking for something and don't know which project it is on, so want to quickly jump around and select a few.

Let's get back to the original request: As a developer, I want to see a list of "my pipelines". So anything I've triggered across projects. Then drop down a level and ask "why do you want a list of my pipelines", and the answer is likely because they want to a) see if everything is passing and b) find failures to investigate. So filtering by state, or at least sorting by state, could work there.

mentioned in issue #21454 (closed)

Yes some kind of toggle for subscribed would work here indeed, however wouldn't it be cool if you could see/filter other people subscriptions as well?

Meaning a subscribers dropdown as well..

Say I want to find a pipeline I am subscribed to and someone else as well ( chances are small, but still could come in handy, plus then its in line with the rest of the dropdowns )

Bigger issue is we should create the functionality to see your subscribed pipelines, MR and issues: https://gitlab.com/gitlab-org/gitlab-ce/issues/12697

mentioned in issue #12697 (moved)

@dimitrieh Is someone's subscriber state "public" information? Is it == "participants" in the sidebar? If not, I'd be afraid of privacy issues. Granted it's not a big deal, but we shouldn't be leaking the fact that someone did or did not subscribe to something. Unless of course we already do. :)

Say I want to find a pipeline I am subscribed to and someone else as well ( chances are small, but still could come in handy, plus then its in line with the rest of the dropdowns )

If chances really are small, then don't do it. :) Unless the consistency in designing the drop-downs is that much worth it.

@markpundsack got ya on the privacy thing

I tested it out and its not the same actually... participants are people that are mentioned or actively contributed to the issue. So yes at the moment this is private information.. mmmh

So yes, for subscribed we'd need a toggle.

In the issue I mentioned this issue in I entertain the usecase in a different light which makes additional sense ;) , but maybe not for subscribed status, but for participants (which is almost but not totally the same)

Usecase: you want to find an issue you are sure of you and someone else contributed towards, but both of you didn't author it.

So if we had a "participants" dropdown we could filter on issues where we know someone is mentioned or actively contributed towards.

Also participants is part of the sidebar, where all other parts are filterable options..

Yep. Participants works. And I've wanted to use it sometimes.

mentioned in issue #21747 (closed)

cc: @tauriedavis

Mentioned in issue #22137 (moved)

Mentioned in commit ubudzisz/gitlab-ce@f1083ba1

We will work on that next release.

Milestone changed to %8.13

Discussed on HN https://news.ycombinator.com/item?id=12488290

Please keep this simple in the first iteration.

Mentioned in issue #22445 (closed)

@dimitrieh This should be able to use the new filters when those are complete, correct?

Milestone changed to %8.14

Mentioned in issue #23492 (closed)

@tauriedavis absolutely! Perhaps me and @cperessini should work together on this at least for the filters part to make sure its in line with his issue https://gitlab.com/gitlab-org/gitlab-ce/issues/21747

Will work on this for upcoming release!

Mentioned in issue #22689 (closed)

Reassigned to @dimitrieh

Milestone changed to %29

FWIW we use gitlab for our internal only git hosting and CI. The only thing we care about is a global list of running pipelines so we can see when/where things are queueing up, so we know how/when to scale. We don't need any of the complexity around subscribing, starring etc mentioned above. We basically just want to see a queue of builds for all projects in a group. That'd help us tremendously and might be a good, simple first iteration

Mentioned in issue #24643 (closed)

Added ~897282 label

Removed ~15078 ~307502 labels

Mentioned in issue #25194 (moved)

removed assignee

mentioned in issue #25425 (closed)

+1 for @bradrobertson, this issue is way more than really needed. Companies and teams need a dashboard... but #3235 (moved) was closed in favor of this.

@bradrobertson is that just a mockup or already code? if code i think this is a valid first step ... lateron we can have squares for each pipeline divided per stage for example ... like the smaller areas in windows startmenu

mentioned in issue #26513 (moved)

removed ~897282 label

mentioned in issue #22558 (closed)

mentioned in issue #29906 (moved)

mentioned in issue #26858 (moved)

@Nowaker Already upvoted the other issue, doing the same here...

Meantime i've played around with https://github.com/marcells/node-build-monitor which is quite ok'ish, but a Gitlab integrated view would be awesome!

not sure, why was the earlier issue closed on this one!! but this is certainly something that is super needed by any org. I am an GitLab EE user and we have a 100's of repositories in my project.. By using Gitlab CI, I am surely missing on this feature of Jenkins which gives you dashboard monitors plugins ... super requirement for the team dev rooms to get a high level picture. How else do we get and radiate this info?

@morph027 you are awesome man .. this is very good solution until #gitlab makes it happen

@markpundsack I'm finding a strong desire to have a view that at least shows me the pipeline status of master, since I want that to be green. Filtering by arbitrary branches will also be useful to check on the status of our CE/EE stable branches.

@stanhu This issue is about the pipeline list, but it sounds like you're talking more about a dashboard like others have discussed above. Is that correct?

@markpundsack To start, I'd be fine with just being able to filter by a single branch. Usually I don't care about the 100 other branches our team is working on; I just care about master or one of the stable branches.

Seems a basic/essential (urgent for me) feature to at least filter down by branch on the UI per project (the current UI).

Looks like you are looking for more features/filters and a more global scope (multi project), maybe it can be split ?

mentioned in issue #36729 (closed)

My 2 cents. It would be nice, to be able to see all pipelines related to given gitlab group for all projects in that group.

mentioned in issue #40188 (closed)

mentioned in issue #39213 (moved)

Hi, ee+ customer here - could really use this.

@dimitrieh we may want to take a look at this as part of our pipeline view improvement plan.

Maybe we can reuse the same design for issue filtering, but I think that something simpler could be the very first iteration. What do you think?

cc @erushton

@bikebilly We can take a look for sure! I am a big fan of reusing the search/filter UI so it becomes more widely adopted/expected :)

added devopsverify label

Not sure if this is the best issue, but the pipeline list on MR's could use some love too. I'm unable to load the pipelines for this MR b/c of the sheer number of them. Basic pagination would be nice.

cc @tlapiana

added customer label

added to epic &358

changed title from Global Pipelines List + Filters for pipelines to Global Pipelines List + Filters for pipelines MVC

changed milestone to %11.8

added Product Vision FY20 label

changed title from Global Pipelines List + Filters for pipelines MVC to Global Pipelines List and filters for pipelines

added [deprecated] Accepting merge requests label

added 1 deleted label and removed 1 deleted label

added Category:Continuous Integration label

changed milestone to %12.3

changed epic to &414 (closed)

mentioned in epic &358

removed from epic &414 (closed)

A premium customer with a large user base are asking for this (ZD internal only: https://gitlab.zendesk.com/agent/tickets/114152)

Is there any update on this issue?

mentioned in issue #58478 (moved)

mentioned in issue #59184 (moved)

changed milestone to %FY20 Q3

marked #12776 (closed) as a duplicate of this issue

mentioned in issue #12776 (closed)

Shooting for %12.3 for this currently

changed milestone to %12.3

The ticket description doesn't list branch name as the filter field. This would be very valuable, e.g. for long lived feature branches (in one repo context) or for displaying only production builds (global pipeline view).

Another missing field is searching jobs by job name. Not sure if global jobs view is in scope of this list, but if it is, searching by job name is very helpful. Even in global context - since job names follow a convention, E.g. name is "deploy".

I agree, especially if the branches are used for deployment like in the GitLab branching model it is very useful to be able to see all pipelines on a production branch so we can for example rollback to previous successful deployment.

mentioned in issue #31690 (closed)

added 1 deleted label

added breadth label

We already have IssuableCollections module that provides capability for the finder and filtering. It could be adapted to be used for PipelinesController#index as well.

Regarding displaying the search bar with the filters we need to add the shared/issuable/search_bar partial and modify SearchHelper#search_filter_input_option to also support inputs for pipelines. On top of this we may need to implement routes and controller actions to fetch the various options for autocomplete.

Finally we need to ensure that all the filters are also implemented as scopes in the Ci::Pipeline model.

changed the description

@jlenny I have looked into this issue and have updated the description with need statement based on user stories found in this thread.

It seems we have main 2 themes going on:

Filtering down the pipeline list (prio 1: user, prio 2: branch, subscribed, contributor, status, latest only, included jobs)
Create a collective pipeline view (prio 1: group, prio 2: instance-personal, instance global)

My suggestion here is to focus first on either one of these, then iterate upon it with the other and the secondary priorities.

Would love your input as to how you want to progress this issue.

As a side comment from our discussion last Friday.

This issue, due to being scheduled for 12.3, is no longer an option to be taken through the full UX research cycle. Therefore the ~"Process::1 Research" stage only depends still on 2 things:

The decision as which need-statement to focus on. (My suggestion here is to focus on defining the filters first)
Only if going for "filters first": Defining exactly what constitutes a user's pipelines. (My suggestion here is to focus on pipelines triggered by that user)

@dimitrieh don't you get the collective view for "free" by setting smart defaults for the filters? I agree some people will have different views of what "my" pipelines are, but something like the following from the description is a reasonable start:

It could just be pipelines that I've triggered (i.e. by pushing a commit)

@jlenny can you elaborate? I am unsure what your idea is.

@dimitrieh if you add filtering, and then have the default filter be "pipelines I've triggered", maybe you've achieved an MVC for both themes.

@jlenny I agree on the fact that filters are the best way forward.

To check if we are on the same line: We currently only have a pipeline list within the context of a project. This would mean that the "collective pipeline view" including filters will be project-based.

@erushton which engineers will I be able to work with on this feature?

@dimitrieh yes that's right (to start.)

@dimitrieh most likely @fabiopitino

@jlenny as discussed this issue will focus on filters first. I have created a follow-up issue which will focus on the scope of making it possible to view your pipelines across a wider context like a group or instance: https://gitlab.com/gitlab-org/gitlab-ce/issues/65040

@erushton thanks! What about frontend?

cc: @jhampton (I'll include you in the meeting for now, please feel free to replace yourself with another FE)

I have set up an ~"Process::2 Ideate" meeting on this to discuss the concept, feasibility, and potential scope.

Thank you @dimitrieh. I will ensure there is a frontend DRI included in the meetings.

@dimitrieh, @shampton will be the DRI for the frontend. He is on holiday during the scheduled meeting (returning 2019-07-30). Would it be possible to reschedule for when he returns? Thanks!

Thanks @jhampton. @fabiopitino is able to join that meeting so will for now rely on him in terms of engineering knowledge.

Thank you @dimitrieh and @fabiopitino!

added 1 deleted label and removed 1 deleted label

changed title from Global Pipelines List and filters for pipelines to Filters for pipelines

mentioned in issue #65040 (moved)

marked this issue as related to #65040 (moved)

changed the description

Slack Channel (Internal Link only) #f_pipeline_filters has been defined.

changed the description

assigned to @fabiopitino

removed [deprecated] Accepting merge requests label

marked #31690 (closed) as a duplicate of this issue

assigned to @shampton

Additional notes from meeting with @jlenny @fabiopitino

Ideation environment

Mural.ly URL (only editable internally)

Notes

Filtering is the most feasible and important for:
- git branch
- git tag
- triggerer
- pipeline status
- commit author
- gitlab pipeline tag (latest, merge request, detached)
Multiple filters will be possible
Filtering is most feasible and important on project pipeline list

Next steps

@fabiopitino do we keep records of who created a git branch and how feasible would it be to be able to filter on that? This way you might be able to see all pipeline statuses for all branches created by you.
I'll create designs in order to showcase this functionality. This will most likely be based on the filter UI presented in the issue list and board.
@fabiopitino @shampton we need to consider if we are able to do repeated filters (additive). For example I might want a collective view of all pipelines belonging to branch A and branch B.
@fabiopitino @shampton we also need to decide on a final scope of this issue. Can you point out what you'll be able to tend to in terms of filtering within this first milestone. I'll base my designs on this decision.
@fabiopitino @shampton As we are likely to copy the search/filter paradigm from the issue/merge request list we will have a default open search functionality in there as well. The question is if this is doable with it querying commit messages. I would say it would be reasonable to limit the amount if need be.

As we are still waiting for feedback on some of the questions at https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_197366226 I will, for now, take the assumption that we want to do the following (we can reduce scope as needed):

filter the project pipeline list on:
- git branch (high priority for scope)
- git tag
- triggerer (high priority for scope)
- pipeline status
- commit author
- gitlab pipeline tag (latest, merge request, detached)
Use the existing search/filter paradigm from the issue/merge request list
Have the default open search functionality querying commit messages.

The following hybrid wireframe mockup showcases this idea:

@fabiopitino @shampton Please see the questions posted at https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_197366226 and with that consider the concept above. If agreed I'll deliver on high fidelity designs including dedicated icons, filter tokens, and final scope.

@jlenny (~~I'll move the required information into the description as discussed~~ => This has been done. Please see if this aligns with your vision as well)

cc: @vkarnes

@dimitrieh Thanks for this design. Here are my responses to your questions from https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_197366226.

we need to consider if we are able to do repeated filters (additive). For example I might want a collective view of all pipelines belonging to branch A and branch B.

I would like the ability to have repeated filters, but we could probably scope that off to a followup issue just to keep this as simple as possible.

we also need to decide on a final scope of this issue. Can you point out what you'll be able to tend to in terms of filtering within this first milestone. I'll base my designs on this decision.

I think the current scope you have listed is good - at least from a frontend perspective.

As we are likely to copy the search/filter paradigm from the issue/merge request list we will have a default open search functionality in there as well. The question is if this is doable with it querying commit messages. I would say it would be reasonable to limit the amount if need be.

I think that's more of a backend question. It shouldn't be hard for the frontend to just send that query to the backend.

The main difficulty on the frontend side is that the pipelines page is written in Vue and the merge requests/issues pages are written in HAML, so the search bar will need to be reimplemented in Vue. It may be already implemented for another page, but I haven't found it yet.

do we keep records of who created a git branch and how feasible would it be to be able to filter on that? This way you might be able to see all pipeline statuses for all branches created by you.

We do not store such information in the database and fetching the author of a branch from Gitaly would be challenging. When we fetch a list of branches from Gitaly we get back also the target commit the branch points to which contains the author but we don't have the original commit that created the branch unless we fetch commits for each branch, which is very expensive. I would suggest we keep this out of the scope for now.

we need to consider if we are able to do repeated filters (additive). For example I might want a collective view of all pipelines belonging to branch A and branch B.

Agree with @shampton to scope it down for now.

we also need to decide on a final scope of this issue. Can you point out what you'll be able to tend to in terms of filtering within this first milestone. I'll base my designs on this decision.

Here is my feedback on the proposed filters (I had more time to dig into the code base rather than going by feeling as during the call):

filter by branch name already exists in https://gitlab.com/gitlab-org/gitlab-ce/-/branches/all but it's a text search and not an autocomplete field like we have for milestone in Issues filter. I'm assuming that autocomplete if backed by Gitaly will be very expensive. We either make branch name filter as text search or add a widget to the filters list similar to the autocomplete ones that would accept a term for search. @shampton would this be something feasible? I'm not seeing anything like this done yet.
filter by git tag is the same problem as above
filter by triggerer should be very simple as we have this data in the database
filter by pipeline status should the same as triggerer
filter by commit author is probably the most difficult because we would need to fetch all commits for an author and we don't even have a Gitaly call for that.
filter by pipeline tag (latest, merge request, detached): seems like we might be able to do merge request and detached but not latest because latest is known "after" fetching the pipeline objects, because we need to compare whether the commit associated to the pipeline is the latest for the ref in the repository.
alternatively there is another filter that we could add easily: filter by source (push, web, trigger, external, api, etc.)

My suggestion is to focus in this milestone to have working filtering capabilities in order to lay the ground work for more filters (possibly more complex ones) later on. So we could focus on just the simple one: by triggerer, by pipeline status, by source (I think it's important too) and a default search that could be by commit message. If branches/tags filter could be added using a term search on pipelines.refs (without autocomplete) we could also add them too.

As we are likely to copy the search/filter paradigm from the issue/merge request list we will have a default open search functionality in there as well. The question is if this is doable with it querying commit messages. I would say it would be reasonable to limit the amount if need be.

Based on my knowledge it should be possible because we already filter by commit message (https://gitlab.com/gitlab-org/gitlab-ce/commits/master) and we could map the sha of each commit with the pipeline sha.

@fabiopitino

We either make branch name filter as text search or add a widget to the filters list similar to the autocomplete ones that would accept a term for search. @shampton would this be something feasible? I'm not seeing anything like this done yet.

I'm not entirely sure how that would work, so maybe it would be better to also scope this off to a followup issue. Is that alright with you, @dimitrieh?

Thanks for the insightful responses here @fabiopitino and @shampton .

The branch name though is a high priority (I would add in "tag" as well in the same way), but has some discussion still. I would deem that more important though than filtering on the commit message (which will be different per commit). Because of that, I think we might be able to reduce scope by text search only on branch/tag.

Filtering/autocomplete by:

trigger author (high priority for scope)
pipeline status
trigger source

Text search by:

branch name (high priority for scope)
tag name

@fabiopitino and @filipa (cc: @shampton) please let me know if this is the scope we can agree on. Higher fidelity mockups including color information following shortly, as well as details on dropdowns and filter tokens.

@eread I do think that trigger author is much clearer than triggerer though a bit more lengthy. I am considering changing this terminology used throughout the interface starting with the filter and the third column inside the pipeline list view. Let me know what you think .

cc: @jlenny @vkarnes

High fidelity mockup showcasing the search and filters

specs

Title	Details	Mockup
Search and filter result	Tabs will adjust their number badges as well
Status filter	Token inherits status color and features pipeline status icon and status name dropdown features pipeline status icons
Trigger author filter	Token features trigger author avatar and name dropdown features trigger author avatar, name, and username
Trigger source filter	Token features trigger source name dropdown features trigger source name
General search	Features 4 options

@fabiopitino @filipa I would like to know if we align on the following lists being complete including the terminology used (cc: @eread):

Pipeline status:

Canceled
Created
Failed
Manual
Not found
Passed
Running
Skipped
Warning

Trigger source:

API
External
Git push
Manual
Schedule

@jeldergl would you be able to give some feedback on the icon usage of the general search dropdown. I feel we might want to consider changing the icons for status and trigger source. In terms of potentially creating those icons, do I/we need to consider the icon redesign effort having an impact on that?

General search dropdown:

Status - icon: status-created

Trigger author - icon: user

Trigger source - icon: fire

@filipa I am intending for us to stay as close as possible to the already implemented filters and search paradigm of https://gitlab.com/gitlab-org/gitlab-ce/issues. Even so, I provided specs. There might be small differences in measurements and color, though I expect those to be fixed eventually by the GitLab UI component effort.

cc: @jlenny @vkarnes

@dimitrieh I'm not sure if this is doable in one single release since the search bar we have is not Vue, and this page is all in Vue.

I'm not sure if it's wise to try to use a non-Vue search bar that is built for issuables (and has issuables filters) and try to tweak it to work with a Vue code base with non-issuables filters.

I will look further into this and let you know.

We may need to consider building something similar in Vue from scratch.

@jhampton

@filipa thanks, waiting for further feedback in that case. If need be we can reduce scope, preferably as long as we keep the "high priority for scope" items in there.

@filipa @dimitrieh

The ~Manage team has similar requirements regarding extending the functionality of our filter bar. There's already an issue planned for 12.2 for creating a search/filter bar in Vue, see https://gitlab.com/gitlab-org/gitlab-ce/issues/57396

Maybe this could be helpful?

@dimitrieh are icons required for the general search dropdown?

If so, then I agree that we could look into creating something new for both based on the new iconography docs.

thanks @wortschi , yes that would be very helpful if we could make an effort to make it reusable. Do you know what is the state of that component?

@filipa As far as I know it should be reusable (since this will eventually end up in gitlab-ui). Looking at gitlab-org/gitlab-services/design.gitlab.com#272 (comment 195626209) it seems that in the first iteration we will primarily focus on porting existing functionality.

Its probably best to create follow-up issues for any additional requirements that we want to build on top if it. WDY?

@xanf please correct me if I didn't understand correctly.

Thanks for the links @wortschi!

@xanf can you please let us know what is the current state, or if we have an ETA? I'm wondering if it would be possible to use this component in this deliverable for 12.3 - do you think this is a reasonable timeline, or not at all?

Thanks everyone!

@filipa please let me know if we need to make any adjustments based on the results of this discussion.

are icons required for the general search dropdown?

@jeldergl the default search dropdown for https://gitlab.com/gitlab-org/gitlab-ce/issues has icons, so ideally we would do the same here. Would you have availability for providing those?

I'm still waiting for feedback from @xanf , will let you know as soon as possible @jhampton

I expect to deliver filters to gitlab-ui somewhere next week (Early next week if there will be no troubles)

Thanks for the update @xanf!

@filipa please let us know your thoughts on the timeline. Thank you!

@jhampton I'd say, let's get backend ready either way and I will do my best to put everything together as soon as @xanf has the components ready.

@xanf can you please update me on slack as soon as it's merged? Could you please link us to the MR here? Thanks!

@filipa will let you know. I'm setting "merge train" for this (there will be multiple changes to multiple components in gitlab-ui), will link final "filters" one as soon as I create it (expected tomorrow)

Thank you @filipa and @xanf !

@dimitrieh I can take a crack at those icons for you.

I don't mind trigger author in our context. We "author" issues and merge requests. We don't say folks are "issuers" or "issue creators", nor "merge requesters" or "merge request creators".

Though, don't we have something in the UI already that is labeled "Triggered by"?

So one could filter on "Triggered by"? rather than "Trigger author"?

WDYT?

added grouppipeline execution label

added Deliverable label

changed milestone to %12.4

I have put this up on the UX/PM agenda for today.

This was moved back into 12.3 based on the discussion from the meeting.

changed milestone to %12.3

changed the description

mentioned in commit gitlab-design@4ce49da6

@filipa assigning this over to you so @shampton has capacity to pick up some Pajamas related efforts in %12.3.

@shampton would you please sync up with @filipa early next week and facilitate any handover discussions. Thank you!

assigned to @filipa and unassigned @shampton

changed the description

assigned to @dimitrieh

changed the description

mentioned in commit gitlab-design@0c109dd5

changed the description

What concepts and procedures should the docs guide and enable the user to understand or accomplish?

This is only available for the project pipeline list currently. You can search or filter down on a certain scope of pipelines across a project's context. For example your own, based on a certain branch, or from a certain source. Additionally, it will be easier to find pipelines with uncommon statusses that have warnings or are not found.

Additive filters will be considered in the future (this might help to see all pipelines from a team working on the same project for example).

To this end, what new page(s) are needed, if any? What pages/subsections need updates? Consider user, admin, and API doc changes and additions.

https://docs.gitlab.com/ee/ci/pipelines.html

For any guide or instruction set, should it help address a single use case, or be flexible to address a certain range of use cases?

It will address a range of use cases by allowing the user to search filter down the pipeline scope across a project's context.

Do we need to update a previously recommended workflow? Should we link the new feature from various relevant locations? Consider all ways documentation should be affected.

https://docs.gitlab.com/ee/ci/pipelines.html#visualizing-pipelines

https://docs.gitlab.com/ee/ci/pipelines.html#accessing-pipelines

Are there any key terms or task descriptions that should be included so that the docs are found in relevant searches?

Filtering pipelines by

Trigger author

Trigger source

Pipeline status

Search pipelines by branch/tag name

Include suggested titles of any pages or subsections, if applicable.

Filtering pipelines by status

Filtering pipelines by trigger author

Filtering pipelines by trigger source

Search pipelines by branch/tag name

@eread @filipa I updated the documentation section of this issue as part of this OKR. A review is welcome .

cc: @jlenny @vkarnes

Really comprehensive, thanks! At least some of the text can be genericized so we don't need to call every filter in new sections.

changed the description

Moving this to ~"Process::3 Implement" as last details are being ironed out but the original ideation session was completed with https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_197366226

added 1 deleted label and removed 1 deleted label

mentioned in issue #65791 (closed)

marked #53189 (closed) as a duplicate of this issue

@dimitrieh here’s some exploration around the icons. I’m not suggesting that A from one has to go with A from another, so you can consider each group independently.

Exploration	Comp

I do like the thought of these being a little more literal and connected though, so for that reason I do like option C from each. If nothing stands out here I’m happy to do more exploration.

@jeldergl thanks! this is looking good. I really like the status icon A. The trigger source icons I am less sure about. What about a lightning bolt or a switch of some kind?

@dimitrieh here are some additional options. I didn’t explore a switch route much, because it gets too close to controls or settings.

Exploration

I’m somewhat partial to B (at scale A is likely more clear though), followed by D.

@jeldergl My gut says: Status A and Trigger-source D

Let me know if you agree and if so if we can deliver these to https://gitlab-org.gitlab.io/gitlab-svgs/

I think that works!

When I was organizing the icons in the gitlab-pattern-library.sketch file I came across this, but noticed it wasn't in the SVG Previewer. So I will likely update that icon, keep the same name and release. Sound fair?

Note that the above icon is for https://gitlab.com/gitlab-org/gitlab-ce/issues/58622

@tauriedavis it's not in the SVG library. So if it exists in the product it's being referenced differently and/or using an SVG not in the current library?

It hasn't been added to the SVG library yet because the issue to add this new icon is still open. Once https://gitlab.com/gitlab-org/gitlab-ce/issues/58622 gets prioritized by product, it'll be added.

@dimitrieh what are your thoughts here? Although I think the icon could work in both places, I’d prefer to keep everything pipeline-related limited to single use.

@jeldergl agreed to keep those uses separate for now. I do agree that the icon can be used in both situations as well.

status_preparing_borderless.svg

status_preparing.svg

My assumption here is that the icon will get a ring around it for the use case of https://gitlab.com/gitlab-org/gitlab-ce/issues/58622 thus looking different from the icon if used for the dropdown in this issue. @tauriedavis is that correct? As there is a version called borderless I think this should be the case.

@jeldergl if so, we should be good to go

@dimitrieh I'll wait for @tauriedavis to chime in, but if the ring is the differentiator then I can update the existing to the new style.

BTW, I got 404’d on your links.

It would be a pipeline status, so I believe it would always have the border or live within a status badge.

That said, we do have this open issue gitlab-design#593 (closed) which discusses a pipeline status icon that is too similar to another one. I think if we use both proposed icons here for different meanings, we may likely end up in a similar situation. What do you think?

added 1 deleted label

Moving to %12.4 as this is blocked on the new Vue component.

As this moves into 12.4, there might be some room for ~"solution validation" prior to that. I'll look into this next week in terms of availability and available testing audience options.

For any community members that are willing to participate, please send the following feedback to my email:

Your use case for using this feature
Your current role and experience
Size of your company/project

In case you reach out, I'll reply next week and communicate what the next steps might be!

cc: @vkarnes

Edit: Other things took priority. Still a good idea to do solution validation after implementation to solidify on workflows like described at https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_208285783

changed milestone to %12.4

removed Deliverable label

mentioned in issue #64643 (closed)

mentioned in commit gitlab-design@5f918dff

added workflowblocked label and removed 1 deleted label

This was moved to 12.4 due to it being dependent on component effort in 12.2 as stated in https://gitlab.com/gitlab-org/gitlab-ce/issues/18054#note_201213879

@filipa are you confident about the scope of this issue for 12.4, stated the component effort will be usable?

From what I understood from both @wortschi and @xanf is that the effort is to make this component 100% reusable.

I'm targeting current functionality (issue filters, etc), but for now i see no extra functionality required in this issue

@xanf what is the current status of the components?

added Dogfooding internal customer production request labels

mentioned in merge request !32131 (closed)

@markpundsack @jlenny @tauriedavis @ayufan @grzesiek Shower thought: I think the underlying problem why people need pipelines filtering is by default all pipelines are displayed. In medium and large sized projects where multiple people work simultaneously on multiple branches, the "Pipelines" view ($PROJECT_URL/pipelines) isn't usable by itself. It's as useless as a hypothetical commits view with all commits sorted by date when they're pushed, and a note what branch each respective commit was pushed to - showing only commits on master by default is a good thing. When I need to find a specific pipeline that executed on master, my current workflow is to open Commits view, and locate pipelines through there. I believe Pipelines should display master branch by default, and offer a way to pick a different branch, or "All branches" (top option in the dropdown). Thoughts?

Makes sense to me also. @dimitrieh this is good UX feedback.

Yes, it makes sense. I would also like to find pipelines easier, but commit message, or anything else, or by failed job name.

Good feedback. The concept layed out in the description will lay the groundwork to support that!

Good point.

added frontend label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue. You can also find more information here:

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Removing milestone from moved item.

removed milestone

New URL for the issue: gitlab#15268 (closed) (for reference)

added to epic &1557

removed from epic &1557

Filters for pipelines

Problem to solve

Intended users

Further details

Proposal

UI

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

Potential follow up problem/need statements

Links / references

Designs

Child items ...

Activity

Ideation environment

Notes

Next steps

Frequently Asked Questions

Filters for pipelines

Problem to solve

Intended users

Further details

Proposal

UI

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

Potential follow up problem/need statements

Links / references

Relates to

Activity

Ideation environment

Notes

Next steps

Frequently Asked Questions