Azure / Azure/azure-dev

Create the first-party azure.springboot extension

Open
#9,961 0 comments 0 reactions 0 assignees View on GitHub
area/extensions area/java area/pipeline
Dominant language
Go
Stars
569
Forks
364
Avg merge
2d 19h
Merged PRs (30d)
136

Description

Create a new first-party extension named `azure.springboot` under `cli/azd/extensions/azure.springboot/` in the Azure/azure-dev repository using `azd x --internal`. This extension will contain Spring Boot-specific implementations of azd extension points while preserving the standard `azd init`, `azd up`, `azd provision`, and `azd deploy` experience.

This issue establishes the extension as a maintained component of the azure-dev repository. It includes the extension package, build and test infrastructure, ownership, preview release path, and contributor documentation needed for subsequent Spring Boot work. It does not implement project detection, infrastructure generation, deployment behavior, or Azure service integrations.

We need to:
- Create the extension as an independent Go module under `cli/azd/extensions/azure.springboot/` using `azd x --internal`.
- Add the standard extension manifest, version file, README, entry point, source packages, and tests.
- Use the existing `azdext` library and follow the conventions established by other first-party extensions in this repository.
- Register only capabilities that are implemented and functional.
- Include the metadata required for azd to identify and start the extension.
- Add unit test, lint, build, and cross-platform packaging coverage consistent with other first-party extensions.
- Add the Azure DevOps release pipeline and registry configuration required to publish preview builds through the existing extension release process.
- Define code ownership for the extension.
- Document how contributors build, test, package, install, and exercise the extension locally.
- Keep azd and extension SDK dependencies aligned with the repository dependency synchronization policy.
- A preview release can be published to the nightly extension registry and installed using the `azure.springboot` ID.
- The installed extension starts successfully and exposes its metadata through the extension framework.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not modify azd core behavior.
- Do not add Spring-specific behavior to shared initialization, project, deployment, or detection code.
- Do not implement missing extension-framework capabilities in this issue.
- Do not add placeholder providers or advertise capabilities that are not functional.
- Do not implement Spring Boot detection, project synthesis, infrastructure templates, deployment targets, or Azure service integrations.
- Do not target Azure Spring Apps, which retires on March 31, 2028.
- If standard `azd` workflows require a missing platform capability, link the appropriate core issue as a dependency rather than adding a workaround or parallel command.

## Repository structure

The change should include the extension-owned equivalents of:

- `cli/azd/extensions/azure.springboot/extension.yaml`
- `cli/azd/extensions/azure.springboot/version.txt`
- `cli/azd/extensions/azure.springboot/go.mod`
- `cli/azd/extensions/azure.springboot/go.sum`
- `cli/azd/extensions/azure.springboot/main.go`
- `cli/azd/extensions/azure.springboot/README.md`
- Extension-local source and test packages
- GitHub workflows for linting and tests
- Azure DevOps release pipeline configuration
- CODEOWNERS updates

Exact file names should follow current first-party extension conventions where they differ from this list.

Contributor guide

Open the contributing guide

Research direction

Start by reading the existing first-party extensions under cli/azd/extensions/ and the azdext conventions, then create azure.springboot with azd x --internal. Work through the listed extension files, workflows, release configuration, and CODEOWNERS updates without adding Spring behavior. Done means the extension builds, tests, lints, packages cross-platform, publishes through the preview path, starts when installed, and exposes only functional metadata and capabilities.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, go
Domain
build-system, ci-cd, cli, developer-experience, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.