Updates the fork lock (which admin-locks new forks) to instead delete
them right away. Helps reduce confusion and abandoned/messy instances
on official corp orgs when used.
* Remove hardcoded references to microsoft (#6)
* add config to some more mail options
Co-authored-by: Moritz Fuchs <moritz.fuchs@sap.com>
Co-authored-by: Tobias Gabriel <tobias.gabriel@sap.com>
- Improved new repository lockdown experience
- Supports swapping description and website URL for repos temporarily until approval
- Supports an initial README commit directing people to the setup experience, if there are no commits yet
- Directly created repos become private immediately but retain access for the initial creator of the repo with read permission
- Removes new repository branch rename feature (GitHub natively supports org-level and enterprise-level custom defaults now)
- Removes 'uuid' dependency to favor newer Node LTS 14+ crypto.randomUUID
- App and job configuration object replaces "treatGitHubAppAsBackground" with "enableAllGitHubApps"
- Table encryption bug fix when pulling from key vault
- Chore: updates NPM dependencies
To work around persistent GitHub bugs we have had the past few years related
to setting the member privilege level for many of our organizations to not
allow members to create repos, we are exploring this new opt-in only feature
flag called "direct new repo lockdown" that will help us to try and experiment
a way to allow our members to directly create repos.
The current prototyping design of this feature is:
1. if a repo is created by a GitHub App (a bot) or an approved system operations account, or the existing new repo workflow, no-op
2. if a repo is created by a member of the GitHub org, the repo is "locked down" - removing their collaborator and team permissions - and they are sent an e-mail asking them to complete the new repo setup by entering into our existing internal wizard for that.
The feature flag must be enabled in 2 places:
1. the app itself must opt in to the feature being available
2. an organization setting must opt in to the feature via configuration
This system requires a few specific parts of the monolithic app to
function: the use of a repository metadata provider (Postgres is what
we are using) to store additional source-of-truth data for a repo,
and also connecting to webhooks either through an org-level webhook
or a GitHub App that has a configured hook.
Jeff Wilcox
mofury
Jeff Wilcox