Runners in the admin view have a distinctly different details view than those in the project and group views. To provide users with the most valuable information about runners, and to improve the consistency of our runner details, a read-only view of runners should be used in the admin view, and eventually for the project and group views.
Problem to solve
Runners in the admin view have a distinctly different details view than those in the project and group views. This is especially confusing when you are jumping from each view as an admin. They are also missing out on important metadata about that runner when only in the admin view, as we don't print out the same details that we do when you are in a project or group.
Eventually, we will be able to reuse this read-only view for developers who do not have access to edit runners. We'll have to do some permission checks to ensure they are able to see the appropriate metadata, but it will open the door for developers to understand more about runners if they ran into a problem.
Implementation Plan
Extra basic details (executor, architecture, platform)
What does success look like, and how can we measure that?
Success would be that administrators are able to solve their runner problems faster by finding the appropriate metadata faster. We'd have to compare the current experience to the new one to effectively measure that.
What is the type of buyer?
Is this a cross-stage feature?
Links / references
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
This issue can be taken on before or after the edit view. There will be some backend work needed to show some of the information on the page, but it will be quite simple compared to other features.
I moved this into workflowplanning breakdown as I felt it was ready to be broken down further by you (if you felt it needed to be) AND because I thought it could be added to an upcoming milestone
After reading our group iteration process, I realize we use the ~"candidate" label to identify issues that could be added for an upcoming milestone, I can follow that in the future. I think this single issue can be our SSOT for the read-only view to be added to release notes, referenced for design, and referenced for development.
@DarrenEastman Following our conversation today, I wanted to jot down some notes after reading through our team refinement process. Not sure if this is what you were looking for, but let me know!
Taking this feature as an example, here is what I was thinking in terms of a checklist/process flow:
Is the proposed feature something we should prioritize? Y/N. If yes, then when, and the PM makes the prioritization decision as to the potential when.
Is the proposal something that a developer can execute to, i.e start coding? Y/N If yes, then its ready for development. If no, then further proposal refinement is needed, and this refinement may result in the developer creating additional issues.
So instead of workflow::planning breakdown I would say this issue needs the :workflowrefinement label.
The reason we proposed this simpler approach for the Runner development workflow, is that the current workflow in my opinion suggests there is a one size fits all to development work.
Would we feel conformable releasing this early version of the page to more users? What would we be missing to deliver this (e.g. enable feature flag) as a first iteration?
@mrincon@DarrenEastman and I spoke in our 1:1 yesterday about this - do you have an idea of how we would release this to more users? We also assumed that the feature flag would not be turned on and released until the end of the 14.8 milestone. We were brainstorming on alternative ways of getting feedback on this from customers in the meantime, such as reaching out to our enterprise customers we have relationships with already and ask them to provide us any feedback.
@mrincon Ah I see, so instead of putting it behind a feature flag, we would treat !78483 (merged) as the first iteration of the feature, and then we would continue to add to it, as we do with our other features. IMO, it could be released as is today, I think it is a solid iteration.
@DarrenEastman@gdoyle as we talked about in our sync, let me know if you see any blocker here and I can enable this for our admins so you can proceed to gather feedback
@DarrenEastman Do we have to wait to gather feedback before enabling this to admins? Or did we decide we wanted to do both so we could get the most amount of feedback?
@gdoyle Yes we can enable for our admins as the internal dogfooding can raise issues now.
In parallel, I was looking at the options for usability testing as part of the solution validation process. How feasible is it to use this process for validating the solution?
If it is feasible, I can reach out to a list of known customer contacts that use the Admin UI for managing runners.
@DarrenEastman If we want to use the RITE method, we ideally would've performed it with real customers during solution validation. It isn't really a method to use after implementation, as it is used to identify current problems with the UI and solve for them. The reason is that the RITE method calls for there to be rapid testing and iterating throughout - meaning that if we met with a single user who gave feedback to move things in the UI, we would continuously move the things in the UI throughout the research project until users we met with after were happy with it. It isn't as feasible to do that with the real code IMO as we have other priorities.
Yes we can enable for our admins as the internal dogfooding can raise issues now.
I have enabled this feature on production so our admins should be able to see it now. See more details about the rollout at #350164 (comment 821904884)
For future iterations, how feasible is it to have new features that have not yet shipped, be made available on the demo systems?
The features listed in the description are up to date.
The feature flag is enabled by: !80726 (merged), still pending to merge as well.
This is a screen of the current state:
There are some features that won't make the cutoff:
Three basic details (executor, architecture & platform)
Filtering assigned projects
Delete button in the corner
The features are not blocked or have any specific problems, but I simply didn't manage to get to them on time before the cutoff so they can be opened as follow ups.