In #328518 (closed) we defined a list of runners for administrators, and now we should do the same for projects.
querygetProjectRunners(){# Return all runners that are available for use by this project, as shown in the CI CD settingsproject(fullPath:"my-project"){runners(membership:"DIRECT",# CiRunnerProjectMembershipFilterbefore:"...",# Pagination argumentsafter:"...",first:"...",last:"..."){nodes{# CiRunnerid}}}}
Feature parity requirements:
This GraphQL API to create the UI described at: #33803[Project-runners.png], which will replace our legacy runner UI.
Runners in the list can be filtered by: Project, Group or Instance, which should correspond to the 4 lists fetched by our current UI:
Project: @project_runners + @assignable_runners (the list is separate in the original UI, we can consider merging it in the new UI, or adding @assignable_runners as a new list)
Instance: @shared_runners
Group: @group_runners
Implementation plan
The following table summarizes the queries we'll need to provide in order to replace the existing UI and queries that are currently embedded in the controller:
During troubleshooting an ui/ux issue for group runners, the API response for a group runner's details could have been improved it were to respond with more details about the groups this runner is available for, and what group registered it.
@mrincon I believe so. The only aspect which I'd like to nail is the permissions requirements around this functionality (still need to get around to creating a dedicated issue), but the work can start before that is finalized.
If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
@mrincon after our discussion, I tested this on master branch and as far as I can tell everything is available. I was able to query for the runners in a project using all three types. Pagination is also complete.
I am tempted to call this issue done, but am I missing anything?
Return all runners that are available for use by this project, as shown in the CI CD settings
I believe that we need to make the requirements for this issue clearer.
There are 4 sections in that the project CI/CD runners page: Specific runners, Shared runners, Group runners, and Other available runners. We're showing not only runners assigned to the project, but also available runners. This complexity doesn't seem to be captured in the ask of this issue's description, unless I'm missing something. It should be possible to emulate the first 3 sections with project { runners(type: X) { nodes {...} } }. On the contrary, the last section seems to require a different query (assignableRunners which currently has its logic in this controller).
@pedropombeiro To reach feature parity we only need 3 lists: Specific runners, Shared runners, Group runners, I added more details about the requirements in the description.
Other available runners / assignableRunners
To reach feature parity we will need to provide a way for users to assign runners they own to this project in the UI. I wonder if we can still work on this API without considering this case yet, and wait until we continue work with assignable projects at #360826.
@mrincon have you tried the existing GraphQL API to see how well it aligns with the requirements for this issue? I'm currently giving it a try, and I see numbers that don't match up:
API
screenshot
Current UI - group runners
GraphQL API - group runners
This is because the current UI is leveraging::Ci::Runner.belonging_to_parent_group_of_project(@project.id), where the new GraphQL API is leveraging::Ci::Runner.owned_or_instance_wide(@project.id). So we need to figure out a way to retrofit this new logic into RunnersFinder as part of the refinement for this issue (I've dropped a question on the original commit for the author). For context, owned_or_instance_wide = belonging_to_parent_group_of_project + belonging_to_project + shared runners.
For project runners, the following query returns all project runners regardless of whether they are just available to the project, or enabled on it:
project(...){runners(type:PROJECT_TYPE){}}
A kind of brute force way to determine whether the project runner is already enabled for the current project is to request the list of projects and check for the ID in the returned list:
Added GraphQL: Support `membership` params for projec... (#383510) as a blocker for this issue, since the existing project.runners property does not return the expected set of runners, and therefore we need the ability to specify what we're interested in.
Thanks for checking this @pedropombeiro. I suspect membership would not be too complex too add (if we take it over) but I'll let you and @tschmitke decide if we have capacity to tackle #383510, as it shouldn't come at the cost of other deliverables.
Pedro Pombeirochanged title from GraphQL API: Add "runners" to projects to GraphQL API: Support queries used in Projects::Settings::CiCdController#define_runners_variables
changed title from GraphQL API: Add "runners" to projects to GraphQL API: Support queries used in Projects::Settings::CiCdController#define_runners_variables
Pedro Pombeirochanged the descriptionCompare with previous version
@jreporter it looks like it was indeed a ~stretch for 15.9 but was not carried over to the 15.10 plan. Since it is really close to being merged I think we can pull it into 15.10 and keep it as a ~stretch. cc/ @DarrenEastman
The analytics instrumentation label is automatically applied when featureaddition and workflowready for development labels are applied. We encourage teams to plan for instrumentation at the time of feature development for new features. This label helps ~group::analytics instrumentation to proactively reach out to teams that require instrumentation support. In case instrumentation does not apply to this feature, please feel free to remove the label.