1509133 - manage mozilla-mobile projects with ci-admin

Status: RESOLVED FIXED

(Firefox Build System :: Task Configuration, task)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

Focus seems to be moving closer and closer to being a part of Firefox CI, including CoT, etc. (bug 1409091)

I suspect now is a good time to start managing the related roles and other TC resources using ci-admin/ci-configuration.

I'm a bit confused about
  project-focus
  project-mobile
  project-application-services
though -- are those all involved here, or should some of those remain outside of ci-configuration's purview?  Or to ask the same question differently, when Firefox CI is its own Taskcluster deployment, will all of those still be on that deployment?

Comment 1

[Johan Lorenzo [:jlorenzo]]

Thank you for raising this concern! Just so I answer correctly, what does Firefox CI mean to you?

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Yeah, that is definitely a shockingly but persistently vague concept at Mozilla.

In this case, it means everything that release engineering manages, or that uses release engineering resources.  So if it's using CoT, or the workerTypes used in the Gecko taskgraph (of which, notably and confusingly, gecko-focus is not one), or releng hardware, or the like, then it's included.

This definition gives a pretty clear answer for most stuff, except for WPT (cross-browser and thus distinct from Firefox, but also tightly integrated into Firefox).  Things like Rust or Things Gateway are definitely not Firefox CI.  Servo has sort of crossed the boundary into Firefox CI.  And Focus/Klar seems to be doing a similar thing.  There are definitely things in Firefox CI that are weird fits, like Servo or Cinnarbar mirroring or code-coverage.

This will become much clearer in H1, when Firefox CI will mean "runs on the Firefox CI Taskcluster instance".

Does that help?

Comment 3

[Aki Sasaki (not active)]

These are good questions. I suspect that, per our CI-ACL meetings, that since releng maintains the permissions structures for Focus (etc) that they fall under releng's purview. Also, since we'll be using ci-configuration and ci-admin for our automated scope tests, doing the same for Focus etc makes a lot of sense.

(Whether Focus and other releng-run github repos run on the same cluster as Firefox remains to be seen. Hopefully we can use the same tools, even if they're separate clusters.)

As part of the CI-ACL recommendations, we want to revisit the scriptworker scopes in general, namely

1) document scriptworker scope usage, ideally similar to the way the taskcluster docs [1] do
2) alter the scriptworker scope strings to be both more internally consistent and to be more consistent with taskcluster platform scope strings. For instance, we may want to include an explicit level1/level3 marker in the string.
3) publish the scriptworker scope formats/schemas somewhere. bstack thought the taskcluster team could provide a service to allow for publishing these in a way that looks like the official taskcluster platform scopes.

[1] e.g. https://docs.taskcluster.net/docs/reference/platform/taskcluster-queue/references/api#create-new-task

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Hm, that didn't necessarily clarify this for me.  Is the scriptworker stuff a blocker to this bug?  Which of the three projects should be managed with ci-*?

Comment 5

[Aki Sasaki (not active)]

I don't think the scriptworker scope tasks should block this bug.
I think it makes sense to manage Focus scopes and roles in ci-*; I'm not sure if that's limited to project-focus scopes. If we handle the other mobile products through ci-* (this may make sense soon), that would probably cover all three projects.

Comment 6

[Johan Lorenzo [:jlorenzo]]

Thanks for the explanation, Dustin! Per yesterday's meeting, I think mobile projects should be managed by ci-admin. Releng administrates (and will continue to) these scopes. Moreover, we recently hit a regression because someone changed the scope sets of this projects, having reviews on them would definitely beneficial. 

I agree, scritpworker shouldn't block this bug.

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

So, thinking a bit more about this.. this may be out of my league.

Projects exist to allow ancillary projects to "self-administer", meaning that the scopes etc. for a particular project are managed by clicking and typing in the UI.  But that's exactly the opposite of what ci-admin/ci-configuration are for.

So I think the options are:

 1) manage all of this in ci-admin/ci-configuration, without giving project-admin scopes to people
 2) manage only the grants of admin rights to people (both normal "project-admin" stuff and the special github-repo-admin and worker-admin grants), and let them point-and-click the rest

Option 1 seems like it's the future.  In that case, basically we're granting scopes (for workertypes, etc.) to specific repositories and other scopes (for cancelling tasks, editing secrets, etc.) to specific user groups.  All of which `grants.yml` could take care of pretty easily.  But that would mean removing the self-service nature of projects.

Option 2 would duplicate the existing project-admin roles stuff, leaving the self-serve aspects in place.  But maybe it's not worth automating something that we will just change later?

This seems relevant to discussion in bug 1512631, where some "patterns" for projects are suggested.  I think such patterns are a great way to start to get a handle on the fast-moving, always-unique world of Firefox-associated projects, but releng folks probably are the better people to be deciding what those patterns are.

So I think I jumped the gun in suggesting that we 'manage' these 'projects' since neither of those are well-defined. I'll un-assign myself here, and can either help if/when someone has a better definition, or we can close this bug and re-visit elsewhere the larger question of managing the remaining roles in the Firefox CI TC deployment.

Comment 8

[Tom Prince [:tomprince]]

I definitely think that for mobile stuff that releng handles, (1) is the correct option.

Comment 9

[Johan Lorenzo [:jlorenzo]]

I agree with comment 8.

Comment 10

[Dustin J. Mitchell [:dustin] (he/him)]

Perhaps the best approach is to stop creating new projects and enumerate the existing projects, planning to have a conversation with the people involved in each project and figure out how to handle their needs within ci-admin (likely removing their "project admin" scopes).

Comment 11

[Mihai Tabara [:mtabara]⌚️GMT]

android-components, fenix and reference-browser are all managed under ciadmin since Q1.
focus is still not there because we're still waiting to see the outcome to that story. app-services is tracked in RelEng under a different bug.

I believe we can close this now. Please re-open should I missed anything.