Re: Introducing Flight Deck: Infrastructure-as-Code for Debian Go Team Repositories
Hi Arthur!
Thanks for working on this! I think this is a great idea and could
help us manage all team packaging repos in "proper devops" style. It
would also be easier for newcomers to request a new repo and ownership
of if by filing a MR on the list of team repos instead of current
`dh-make-golang create-salsa-project` that does create the project
with correct settings, but does not grant permissions to the new
contributor to actually use it. Using Flight Deck would also make it
easier and more transparent on how and when we update package/project
defaults such as branch names or CI settings.
Hopefully others in the Go team could check this out. The README at
https://salsa.debian.org/go-team/flight-deck is pretty good!
On Tue, 26 Aug 2025 at 11:43, Arthur Diniz <arthurbdiniz@gmail.com> wrote:
>
> Dear Go Team,
>
> I hope this email finds you well.
>
> I'm excited to introduce Flight Deck, a new centralized infrastructure-as-code solution that I've been developing to address the growing challenges of managing our extensive repository ecosystem.
>
> Just like an airplane's cockpit provides centralized control for the entire aircraft, Flight Deck serves as our single source of truth for controlling and configuring all repositories within our Salsa instance.
>
> https://salsa.debian.org/go-team/flight-deck
>
> THE CHALLENGE WE FACE
>
> As our team has grown, so has the complexity of managing our repositories.
>
> Currently, the packages subgroup alone contains approximately 3,300 repositories, each requiring consistent configuration for:
>
> - Branch protection rules
> - Webhook integrations (tagpending, IRC notifications)
> - Repository badges and metadata
> - CI/CD pipeline configurations
> - Access controls and permissions
>
> Maintaining this scale manually or through custom scripts leads to:
>
> - Significant time investment in development and maintenance
> - Configuration drift across repositories
> - Inconsistent setups that can impact our workflow
> - Manual errors when creating or updating repositories
>
> Why Flight Deck? Flight Deck leverages OpenTofu (Terraform) and Terragrunt with GitLab's provider to manage our Salsa infrastructure as code.
>
> Benefits:
>
> - Automated Repository Creation: Interactive tools for creating repositories with consistent configuration
> - Standardized Branch Protection: Automatic setup for debian/*, upstream/*, upstream, pristine-tar, and master branches
> - Integrated Webhook Management: Default webhooks for tagpending notifications and IRC integration
> - Consistent Badges: Automatic Contributors and Debian unstable badges
> - Infrastructure as Code: All configurations version-controlled and reviewable
> - Bulk Operations: Import and manage multiple repositories efficiently
> - State Management: Remote state with automatic locking prevents conflicts
>
> Flight Deck uses a safe, pipeline-driven approach during deployment process:
>
> 1. Development: Create/modify configurations in merge requests
> 2. Validation: Automatic planning and validation in MR pipelines
> 3. Deployment: Manual approval required for applying changes
> 4. Rollback: Simple revert process for emergency situations
>
> FEATURE PARITY WITH PKG-GO-TOOLS
>
> We're actively working to bring feature parity with our existing pkg-go-tools infrastructure:
> https://salsa.debian.org/go-team/infra/pkg-go-tools
>
> Our progress is being tracked in:
> https://salsa.debian.org/go-team/flight-deck/-/issues/1
>
> CURRENT FEATURES UNDER DISCUSSION
>
> We're currently implementing several key features and would appreciate team input on:
>
> 1. Webhook Management (MR #13):
> https://salsa.debian.org/go-team/flight-deck/-/merge_requests/13
>
> Flight Deck automatically configures two essential webhooks for every repository:
> - Tagpending Webhook: https://webhook.salsa.debian.org/tagpending/{repository-name} for package tagging notifications
> - KGB IRC Webhook: http://kgb.debian.net:9418/webhook/?channel=%23debian-golang for real-time team updates
>
> The system supports:
> - Disabling default webhooks with enable_default_webhooks = false
> - Adding custom webhooks via additional_webhooks variable
> - Bulk importing existing webhook configurations
>
> 2. Master Branch Protection (MR #14):
> https://salsa.debian.org/go-team/flight-deck/-/merge_requests/14
>
> Adding protection for the master branch alongside our existing protections for Debian-specific branches, ensuring consistent access controls across all critical branches.
>
> CURRENT STATUS
>
> Flight Deck is currently in an opt-in phase. We have successfully imported and are managing repositories from myself (arthurbd@) and otto@, demonstrating the system's capability.
>
> I believe Flight Deck will significantly improve our team's efficiency and repository consistency. Your feedback on the current merge requests would be invaluable as we finalize these core features.
>
> Thank you for your time and consideration. I look forward to your feedback and collaboration as we continue to improve our team's infrastructure.
>
> Best regards,
> Arthur Diniz
>
Reply to: