Change Details

Forking task from outline in T117071#2201228. ### Requirements Create an application that uses the various conduit APIs to: * Create a repository * Manage the "Editable By" and "Can Push" policies for a repository that has been created through the tool To keep things simple, all repos managed by the app will have some uniform characteristics: * Repo name is "tool-<service group name>" (e.g. "tool-verisons" for `tools.versions`) * Repo callsign is "TOOL<gid of service group>" (e.g. "TOOL52937" for `tools.versions`) * "Dangerous Changes" flag (force push and branch delete) enabled * All members of the tool having a Phabricator account at the time the repo is created are granted edit and push rights. (We can live with Phabricator users needing to be added manually in the app if we can't find a method to map from LDAP users to Phabricator users automatically.) Some additional simplifying assumptions for the initial tool: * A repo is associated with a single shared tool account (service group) * Management of the repo via the tool is granted to all members of the tool account (maintainers) * Only one repo per tool is allowed ** We can add support for multiple repos as a later improvement * The tool will not manage mirrors, staging, automation, or any other advanced diffusion settings. These features can be handled manually via Phabricator tickets by members of the repository-admins group. This set of functions provides the bare minimum needed to publish the code for a tool, namely a web accessible version control system. By adding an `.arcconfig` file to the repository this bare minimum can be expanded to allow code submission as well via arcanist/differential. ### Constraints The application needs access to LDAP data on service group membership for authorization (only managers of a tool should be able to modify the settings for a repo) and an authentication (login) method that can be correlated with the group members. The authz information needed is available within Labs/Tool Labs, but currently there is no suitable authn solution. SUL OAuth is available to tools today, but SUL accounts have no correlation with wikitech accounts and/or LDAP data. If we want to write new data into the LDAP directory, the application can not be hosted in either Tool Labs or Labs generally. Access to the credentials needed to modify LDAP cannot be properly secured inside the Labs environment. This means that the app will need to be hosted in the production side of the WMF network.

Forking task from outline in T117071#2201228. ### Requirements Create a web application that uses the various conduit APIs to: * Create a Diffusion repository based on an existing Tool Labs project * Automatically set-up the "Editable By" and "Can Push" policies for the repository created through the tool, and also provide a UI to allow project owners to manage that To keep things simple, all repos managed by the app will have some uniform characteristics: * Repo name is "tool-<service group name>" (e.g. "tool-verisons" for `tools.versions`) * Repo callsign is "TOOL<gid of service group>" (e.g. "TOOL52937" for `tools.versions`) * "Dangerous Changes" flag (force push and branch delete) enabled * All members of the tool having a Phabricator account at the time the repo is created are granted edit and push rights. (We can live with Phabricator users needing to be added manually in the app if we can't find a method to map from LDAP users to Phabricator users automatically.) Some additional simplifying assumptions for the initial tool: * A repo is associated with a single shared tool account (service group) * Management of the repo via the tool is granted to all members of the tool account (maintainers) * Only one repo per tool is allowed ** We can add support for multiple repos as a later improvement * The tool will not manage mirrors, staging, automation, or any other advanced diffusion settings. These features can be handled manually via Phabricator tickets by members of the repository-admins group. This set of functions provides the bare minimum needed to publish the code for a tool, namely a web accessible version control system. By adding an `.arcconfig` file to the repository this bare minimum can be expanded to allow code submission as well via arcanist/differential. ### Constraints The application needs access to LDAP data on service group membership for authorization (only managers of a tool should be able to modify the settings for a repo) and an authentication (login) method that can be correlated with the group members. The authz information needed is available within Labs/Tool Labs, but currently there is no suitable authn solution. SUL OAuth is available to tools today, but SUL accounts have no correlation with wikitech accounts and/or LDAP data. If we want to write new data into the LDAP directory, the application can not be hosted in either Tool Labs or Labs generally. Access to the credentials needed to modify LDAP cannot be properly secured inside the Labs environment. This means that the app will need to be hosted in the production side of the WMF network.

Forking task from outline in T117071#2201228. ### Requirements Create an web application that uses the various conduit APIs to: * Create a Diffusion repository based on an existing Tool Labs project * Manage* Automatically set-up the "Editable By" and "Can Push" policies for athe repository that has been created through the toolcreated through the tool, and also provide a UI to allow project owners to manage that To keep things simple, all repos managed by the app will have some uniform characteristics: * Repo name is "tool-<service group name>" (e.g. "tool-verisons" for `tools.versions`) * Repo callsign is "TOOL<gid of service group>" (e.g. "TOOL52937" for `tools.versions`) * "Dangerous Changes" flag (force push and branch delete) enabled * All members of the tool having a Phabricator account at the time the repo is created are granted edit and push rights. (We can live with Phabricator users needing to be added manually in the app if we can't find a method to map from LDAP users to Phabricator users automatically.) Some additional simplifying assumptions for the initial tool: * A repo is associated with a single shared tool account (service group) * Management of the repo via the tool is granted to all members of the tool account (maintainers) * Only one repo per tool is allowed ** We can add support for multiple repos as a later improvement * The tool will not manage mirrors, staging, automation, or any other advanced diffusion settings. These features can be handled manually via Phabricator tickets by members of the repository-admins group. This set of functions provides the bare minimum needed to publish the code for a tool, namely a web accessible version control system. By adding an `.arcconfig` file to the repository this bare minimum can be expanded to allow code submission as well via arcanist/differential. ### Constraints The application needs access to LDAP data on service group membership for authorization (only managers of a tool should be able to modify the settings for a repo) and an authentication (login) method that can be correlated with the group members. The authz information needed is available within Labs/Tool Labs, but currently there is no suitable authn solution. SUL OAuth is available to tools today, but SUL accounts have no correlation with wikitech accounts and/or LDAP data. If we want to write new data into the LDAP directory, the application can not be hosted in either Tool Labs or Labs generally. Access to the credentials needed to modify LDAP cannot be properly secured inside the Labs environment. This means that the app will need to be hosted in the production side of the WMF network.