Code Monkey home page Code Monkey logo

draft's Introduction

Draft logo


Draft

A tool to help developers hit the ground running with Kubernetes.

Report Bug · Request Feature

Draft Unit Tests GoDoc Go Report Card CodeQL Draft Linux Integrations Draft Release & Publish

Getting Started

Draft is a tool made for users who are just getting started with Kubernetes, or users who want to simplify their experience with Kubernetes. This readme will give you a quick run down on Draft’s commands and what they do.

draft create

In our directory that holds our application, we can run the CLI command ‘draft create’. Draft create will walk you through a series of questions prompting you on your application specification. At the end of it, you will have a Dockerfile as well as Kubernetes manifests to deploy your application. Below is a picture of running the Draft create command on our Contoso Air repository.

example of draft create command showing the prompt "select k8s deployment type" with three options "helm", "kustomize", and "manifests"

generate-workflow

Next up, we can run the ‘draft generate-workflow’ command. This command will automatically build out a GitHub Action for us. screenshot of command line executing "draft generate-workflow" printing "Draft has successfully genereated a Github workflow for your project"

setup-gh

If you are using Azure, you can also run the ‘draft setup-gh’ command to automate the GitHub OIDC setup process. This process is needed to make sure your Azure account and your GitHub repository can talk to each other. If you plan on using the GitHub Action to deploy your application, this step must be completed.

screenshot of command line executing "draft setup-gh" showing the prompt "Which account do you want to log into?" with two options "Github.com" and "Github Enterprise Server"

At this point, you have all the files needed to deploy your application onto a Kubernetes cluster!

If you don’t plan on using the GitHub Action, you can directly apply your deployment files by using the kubectl apply -f command.

If you plan on deploying your application through your GitHub Action, commit all the files to your repository and watch your application get deployed!

draft validate

Draft validate scans your manifests and populates warnings messages in your code terminal if your manifests are not following best practices. All best practices are sourced from AKS’s deployment safeguards feature. To learn more about deployment safeguards, visit the offical documentation. To view the best practices that are used in Draft, view the safeguards package.

screenshot of draft-validate

draft info

The draft info command prints information about supported languages and deployment types.

Example output (for brevity, only the first supported language is shown):

{
  "supportedLanguages": [
    {
      "name": "clojure",
      "displayName": "Clojure",
      "variableExampleValues": {
        "VERSION": [
          "8-jdk-alpine",
          "11-jdk-alpine"
        ]
      }
    }
  ]
  ...,
  "supportedDeploymentTypes": [
    "helm",
    "kustomize",
    "manifests"
  ]
}

About The Project

Draft makes it easier for developers to get started building apps that run on Kubernetes by taking a non-containerized application and generating the Dockerfiles, Kubernetes manifests, Helm charts, Kustomize configuration, and other artifacts associated with a containerized application. Draft can also generate a GitHub Actions workflow file to quickly build and deploy applications onto any Kubernetes cluster.

Commands

  • draft create adds the minimum required Dockerfile and manifest files for your deployment to the project directory.
    • Supported deployment types: Helm, Kustomize, Kubernetes manifest.
  • draft setup-gh automates the GitHub OIDC setup process for your project.
  • draft generate-workflow generates a GitHub Actions workflow for automatic build and deploy to a Kubernetes cluster.
  • draft update automatically make your application to be internet accessible.
  • draft validate scan your manifests to see if they are following Kubernetes best practices.
  • draft info print supported language and field information in json format.

Use draft [command] --help for more information about a command.

Dry Run

The following flags can be used for enabling dry running, which is currently supported by the following commands: create

  • --dry-run enables dry run mode in which no files are written to disk
  • --dry-run-file specifies a file to write the dry run summary in json format into
// Example dry run output
{
  "variables": {
    "APPNAME": "testapp",
    "BUILDERVERSION": "null",
    "IMAGENAME": "testapp",
    "LANGUAGE": "gomodule",  // Note that this variable is in addition to the draft config variables
    "NAMESPACE": "default",
    "PORT": "1323",
    "SERVICEPORT": "80",
  },
  "filesToWrite": [
    "langtest/.dockerignore",
    "langtest/Dockerfile",
    "langtest/charts/.helmignore",
    "langtest/charts/Chart.yaml",
    "langtest/charts/production.yaml",
    "langtest/charts/templates/_helpers.tpl",
    "langtest/charts/templates/deployment.yaml",
    "langtest/charts/templates/namespace.yaml",
    "langtest/charts/templates/service.yaml",
    "langtest/charts/values.yaml"
  ]
}

Prerequisites

Draft requires Go version 1.18.x. or above as it uses go generics

Check your go version.

go version

Installation

  1. Clone the repo

    git clone https://github.com/Azure/draft.git
  2. Change to the draft directory and build the binary

    cd draft/
    make
  3. Add the binary to your path (we use the same directory as go install)

    mv draft $HOME/go/bin/

Install with HomeBrew

  1. Run the following commands

    $ brew tap azure/draft
    $ brew install draft

Installation using script

curl -fsSL https://raw.githubusercontent.com/Azure/draft/main/scripts/install.sh | bash
  • Windows isn't currently supported (you can use WSL)

Draft as a Dependency

If you are looking to leverage Draft's file generation capabilities and templating within another project instead of using the CLI, you have two options: importing the Draft go packages, and wrapping the binary

Importing Draft Go Packages

This option will provide the cleanest integration, as it directly builds Draft into your project. However, it requires that your project is written in Go.

Dockerfiles can be generated following the example in examples/dockerfile.go

Deployment files can be generated following the example in examples/deployment.go

Wrapping the Binary

For projects written in languages other than Go, or for projects that prefer to not import the packages directly, you can wrap the Draft binary.

Several features have been implemented to make consuming draft as easy as possible:

  • draft info prints supported language and field information in json format for easy parsing
  • --dry-run and --dry-run-file flags can be used on the create and update commands to generate a summary of the files that would be written to disk, and the variables that would be used in the templates
  • draft update and draft create accept a repeatable --variable flag that can be used to set template variables
  • draft create takes a --create-config flag that can be used to input variables through a yaml file instead of interactively

Introduction Videos

Day Zero Draft

Get your app & APIs on Kubernetes fast with Draft

Contributing

Draft is fully compatible with Azure Kubernetes Service. We strongly encourage contributions to make Draft available to other cloud providers 😊!

Issues/Discussions

The Draft team will be monitoring both the issues and discussions board. Please feel free to create issues for any problems you run into and the Draft team will be quick to respond. The discussions board will be used for community engagement. We look forward to see you there!

License

Draft is under the MIT License. See LICENSE for more information.

Trademark Notice

Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party’s policies.

draft's People

Contributors

aamgayle avatar asw101 avatar bcho avatar bfoley13 avatar bosesuneha avatar davidgamero avatar dependabot[bot] avatar erinborders avatar gambtho avatar github-actions[bot] avatar hsubramanianaks avatar imiller31 avatar jaiveerk avatar jldeen avatar karenychen avatar lukemurraynz avatar meecethereese avatar olivermking avatar qpetraroia avatar rguptar avatar smurawski avatar tatsinnit avatar tbarnes94 avatar vidya2606 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

draft's Issues

Proposal: Move e2e from bash/gh actions to golang

Is your feature request related to a problem? Please describe.
The current draft e2e is written in bash across a series of files, which yield a set of tremendous github workflow yamls

This cannot be run locally easily, and has a high adoption cost to get into the build-test-iteration loop

Migrating to a go-based testing framework for e2e would allow the tests to be run locally easier, and make them much faster to test

Describe alternatives you've considered
Keep the tests in gh actions

Additional context
something like the testing implemented in https://github.com/Azure/aks-app-routing-operator by @OliverMKing

Draft Create Auto Detect .gradle file during Java detection

Is your feature request related to a problem? Please describe.
When running draft create on the following repo, draft prompts for gradle or maven https://github.com/codecov/example-java-gradle

[Draft] --- Detecting Language ---
Use the arrow keys to navigate: ↓ ↑ → ←
? Linguist detected Java, are you using maven or gradle?:
  > gradle
    maven

Mention what platform you want to support the new feature
OSS

Describe the solution you'd like
Draft should detect the *.gradle files in a repository to determine if gradle is used.

Describe alternatives you've considered
A better method for detecting gradle or maven could be used. The build files are the best way I could determine.

Additional context
(none)

draft setup-gh fails with error

draft setup-gh fails with the following error:

$ draft setup-gh
✔ azure
Enter app registration name: ???
✔ ???
Enter resource group name: ???
Enter github organization and repo (organization/repoName): ???/???
[Draft] --> Setting up Github OIDC... ⡿ [Draft] ERROR: usage error: --assignee STRING | --assignee-object-id GUID

az version output:

$ az version
{
  "azure-cli": "2.33.1",
  "azure-cli-core": "2.33.1",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "containerapp": "0.3.4",
    "log-analytics": "0.2.2",
    "tipsextension": "0.0.1"
  }
}

I will submit a PR for this in a moment.

`draft info` command proposal

Is your feature request related to a problem? Please describe.
Draft's current capabilities are designed to be easy to wrap, and should be implementable by other services easily.

In order to make supported language and field discovery easier, I proposed adding a draft info command that prints supported deployment types, languages, and other important configuration information in a parsing-friendly format such as yaml or json.

Mention what platform you want to support the new feature
The base draft cli tool should implement this feature to allow easy discovery of the available values for dependent services.

For a first milestone, I suggest a default output of json for the draft info command, that prints the following properties: supportedLanguages and supportedDeploymentTypes each as an array of strings.

Future milestones could include:

  • supported addons list
  • yaml output support using an output flag ex: draft info -o yaml
  • printing builder variables for a specified template, or all templates (to make consuming the binary easier)

Describe the solution you'd like
The draft info command should return a standardized output similar to the following:

{
  "supportedLanguages": [
    "javascript",
    "gomodule",
    ...
    "csharp"
    ],
  "supportedDeploymentTypes": [
    "manifest",
    "helm",
    "kustomize"
  ]
}

Describe alternatives you've considered
One alternative route is to publish a file that includes this information the draft repo, so that it can be referenced by other projects, potentially bundling an additional file with each release that details the available commands.
This alternative approach would incur more file-management, and break the single-binary goal of the current cli tool.

Additional context
To further the goal of making draft an extensible, opinionated tool with baked-in best practices, it must be not only extensible, but discoverable. Adding an info command is a step towards making draft even easier to rely on from an external service.

Unnecessary Action Runs on PRs

integration tests run on all PRs, even ones where only the README is changed.

Ref @hsubramanianaks 's comment on #220

We currently have several actions whose success is required in order to allow a PR to merge, so if we wanted to allow PRs for the README to merge without having to run all the tests, we may have to change the Required Checks which I'm not sure we can do per-file since last time I updated them it was a per-repository setting

Custom logic in the checks seems limited since you can't depend on other checks without some very custom tooling to probe the actions api, but if it's possible we should definitely do this!

Support a true GitOps workflow

Is your feature request related to a problem? Please describe.
As a user, I'd like to be able to utilize true pull-based GitOps workflows for Day 1/2+ operations after getting started. The existing push-based model does not scale as the number of applications, teams, and clusters grow.

Mention what platform you want to support the new feature
Has implications possibly across all of: az-extension, oss draft, and vscode.

Describe the solution you'd like

  1. draft create provisions a GitOps-friendly/planned repo structure and optionally wraps the structure in ArgoCD application(Set).
  2. draft setup-gh or likely alternative command bootstraps the cluster with ArgoCD agent sync'ed to the repo specified
  3. draft generate-workflow still sets up the pipeline to build the container image, but it does not authenticate/kubectl apply push down to the cluster. The ArgoCD agent in the previous step will automatically install the newly created container image after it is merged into the proper git directory as specified previously.

Describe alternatives you've considered
https://github.com/gitops-bridge-dev/gitops-bridge-argocd-control-plane-template
https://github.com/argoproj-labs/argocd-autopilot
https://github.com/alexellis/arkade?tab=readme-ov-file#catalog-of-clis -- ArgoCD

Having issue running az aks draft create getting error

Describe the bug
Having issue running az aks draft create produces an error

To Reproduce
Steps to reproduce the behavior:

Updated CLI

  1. az extension add --name aks-preview
  2. az extension update --name aks-preview

Draft Issue

  1. created new api with the dotnet new webapi -n DraftApi
  2. cd into the directory
  3. ran in cmd prompt az aks draft create
  4. See an error

Expected behavior
I expected Draft create to work create Dockerfiles etc.

Screenshots
PS C:\Users\tioleson\Draft> az aks draft create --destination /DraftApi
The command failed with an unexpected error. Here is the traceback:
cannot import name 'map_azure_error_to_cli_error' from 'azure.cli.command_modules.acs._helpers' (C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\site-packages\azure\cli\command_modules\acs_helpers.pyc)
Traceback (most recent call last):
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 231, in invoke
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 583, in execute
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/parser.py", line 261, in parse_args
File "argparse.py", line 1768, in parse_args
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/parser.py", line 284, in parse_known_args
File "argparse.py", line 1800, in parse_known_args
File "argparse.py", line 1988, in _parse_known_args
File "argparse.py", line 1965, in consume_positionals
File "argparse.py", line 1874, in take_action
File "argparse.py", line 1159, in call
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/parser.py", line 284, in parse_known_args
File "argparse.py", line 1800, in parse_known_args
File "argparse.py", line 1988, in _parse_known_args
File "argparse.py", line 1965, in consume_positionals
File "argparse.py", line 1858, in take_action
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/parser.py", line 275, in _get_values
File "argparse.py", line 2399, in _get_values
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/parser.py", line 326, in _check_value
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/parser.py", line 201, in get_examples
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/_help.py", line 192, in get_examples
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/help.py", line 253, in init
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/_help.py", line 303, in load
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/help_loaders.py", line 154, in versioned_load
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/help.py", line 198, in load
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/parser.py", line 241, in getattribute
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 133, in description_loader
File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 59, in get_op_handler
File "importlib_init
.py", line 127, in import_module
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "C:\Users\tioleson.azure\cliextensions\aks-preview\azext_aks_preview\custom.py", line 105, in
from ._helpers import (
File "C:\Users\tioleson.azure\cliextensions\aks-preview\azext_aks_preview_helpers.py", line 7, in
from azure.cli.command_modules.acs._helpers import map_azure_error_to_cli_error
ImportError: cannot import name 'map_azure_error_to_cli_error' from 'azure.cli.command_modules.acs._helpers' (C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\site-packages\azure\cli\command_modules\acs_helpers.pyc)

Desktop (please complete the following information):

  • OS: Windows 11 Enterprise
  • Browser Edge and Chrome
  • Version latest
  • OS Build 22000.739

Missing namespace in deploy step when using kustomize deployment target

Describe the bug

When creating a project using deployment type kustomize, the cli wizard will ask for target namespace:

✔ Please enter  the namespace to place new resources in (default: default): 

When using a non-default namespace, for example foo, the wizard will create the k8s deployment configuration like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: draft-demo
  labels:
    app: draft-demo
  namespace: foo

However, the later workflow setup wizard will not prompt for target namespace, and generate a deployment step like this:

# Deploys application based on manifest files from previous step
      - name: Deploy application
        uses: Azure/k8s-deploy@v4
        with:
          action: deploy
          manifests: ${{ steps.bake.outputs.manifestsBundle }}
          images: |
            ${{ env.AZURE_CONTAINER_REGISTRY }}.azurecr.io/${{ env.CONTAINER_NAME }}:${{ github.sha }}

This deployment step will deploy to default namespace by default:

Run Azure/k8s-deploy@v4
  with:
    action: deploy
    manifests: <omitted>
    images: <omitted>
  
    namespace: default # <---- default value for namespace
    pull-images: true
    strategy: basic
    route-method: service
    version-switch-buffer: 0
    traffic-split-method: pod
    percentage: 0
    force: false
    token: ***
    annotate-namespace: true
    private-cluster: false
    skip-tls-verify: false

Hence, the deployment will fail with error like:

the namespace from the provided object "foo" does not match the namespace "default". You must pass '--namespace=foo' to perform this operation.

Mention the platform you are using

OSS draft

To Reproduce
Steps to reproduce the behavior:

See above description.

Expected behavior

When using kustomize deployment target:

  1. the namespace should be set in kustomization.yaml instead of k8s object spec. By using a kustomization level namespace settings, we can ensure all controlled k8s objects are created under the same namespace.
  2. namespace settings should set in the deploy GitHub Action step.

add support for requirements.txt

Is your feature request related to a problem? Please describe.
Make the python dockerfile run pip install requirements.txt if the file exists at the root

we could inline it with something like [ -f "/requirements.txt" ] && pip install requirements.txt so that it only runs if the file is there

Mention what platform you want to support the new feature
oss draft

Describe the solution you'd like
when a repo is supplied to draft with a requirements.txt, it should install them

when a repo is supplied without a requirements.txt, this step should be skipped

Describe alternatives you've considered
making a new prompt or separated dockerfile for "python_with_requirements"- but this seems like extra complexity and maintenance burden when we could just add it to the one dockerfile we already have

Additional context

`draft generate-workflow` drops tag when updating the deployment manifest

Describe the bug

When using draft generate-workflow, the deployment manifest created by draft create is updated based on the ACR specified and container image name supplied, but the tag is not requested and therefore lost when the manifest is rewritten.

Mention the platform you are using

Using draft CLI

> draft version  
version:  0.0.33
runtime SHA:  2142dbc745ac8284999f3384358680c7bc6f8570

To Reproduce

git clone https://github.com/smurawski/drafttesting
cd drafttesting
git checkout draft_create

draft generate-workflow -b main \
  -x . \
  -c aks1 \
  --container-name drafttesting \
  --deploy-type manifest \
  --registry-name acrxms72d \
  --resource-group drafttesting

The ./manifests/deployment.yaml file will be updated and the tag for the image lost.

Expected behavior

Ideally, draft would read the existing manifest and default the container registry prompt and image name, as well as offer a prompt for tag with the default of what was in the existing YAML file.

A sufficient result would be achieved if the tag was prompted for and filled in for the deployment.yaml file.

Desktop (please complete the following information):

  • OS: Windows
  • Shell: PowerShell 7.3.6

Add support for Azure DevOps

Is your feature request related to a problem? Please describe.
Before Microsoft acquired Github, there was an stll remain Azure DevOps which is a huge part of many enterprise environments, so I would like to see Draft support Azure DevOps pipeline creation.

Mention what platform you want to support the new feature
Azure DevOps pipelines

Describe the solution you'd like
'generate-workflow' should be able to generate a yaml pipeline for Azure DevOps.

Describe alternatives you've considered
Manually writing Azure DevOps pipeline.

Additional context
N/A

missing installation for jq

Hello there!

Thanks for your work!

Followed the installation instructions on the main README.md and was met with this error.

cd ./test; \
        ./gen_integration.sh; \
        cd ..;
Removing previous integration configs
Removing previous integration workflows
./gen_integration.sh: line 75: jq: command not found

Running on macOS.

Got around with a manual jq installation. Just a heads up!

support draft create on .war files

Is your feature request related to a problem? Please describe.
Support draft create on .war files. We have seen customers not have access to the source code, but still need to generate dockerfiles from the .war file.

Remove second port prompt

Draftv2 create command asks for what port to expose in the app twice so there's the possibility of having a different port exposed in the dockerfile than is exposed in deployment and service yamls - if there's no use case for this, would recommend saving the port so you can skip the second prompt

Proposal: Enrich `draft info` with variable defaults

Is your feature request related to a problem? Please describe.
When consuming draft as a wrapped binary, the available variable defaults for VERSION and BUILDERVERSION are not exposed non-interactively. Exposing these in the info command would make draft more extensible in this pattern.

This would be particularly useful for the aks-devx-tools vscode extension since it is pioneering our binary consumption pattern

The goal of this PR is to remove the need for static files like languages.ts that are sensitive to becoming out-of-date with each incremental draft version, and would require significant extra work to keep in sync with 3rd party draft templates.

Exposing the following information would make the draft binary more extensible:

  • Default values for BuilderVariables in the draft.yaml
  • A formatted/capitalized display name for a selected language/deployType/addon

Mention what platform you want to support the new feature
Mention what platform you would like the feature request to live in (az-extension, oss draft, vscode) and select the proper label.

Describe the solution you'd like

Draft info output

The current info command prints the following format in stdout:

{
  "supported_languages": [
    "javascript",
    ...
  ],
 "supported_deployment_types": [
    "helm",
    ...
  ]
}

I propose enriching this information with the following additional sub fields for each language:

{
  "supported_languages": [
    {
      "name": "javascript"
      "display_name": "JavaScript",
      "exampleValues": {
        "VERSION": [
          "14.0",
          "16.0"
        ]
      }
    }
    ..
  ],
 "supported_deployment_types": [
    "helm"
    ..
  ]
}

draft.yml format changes

In order to better support standardized consumption, I propose changing the value field on the variableDefault type from a string to an array of strings. For the CLI, the first default in the array would be used, but allowing additional defaults can be echoed in the info command to provide examples (ex: providing several recommended versions for a language dockerfile).

# Current abbreviated example for a language draft.yaml
language: swift
variables:
  - name: "VERSION"
    description: "the version of swift used by the application"
variableDefaults:
  - name: "VERSION"
    value: 5.5


# Proposed abbreviated changes for a language draft.yaml
language: swift
displayName: Swift # Add a display name for the selected resource (language/deploymentType/addon)
variables:
  - name: "VERSION"
    description: "the version of swift used by the application"
    exampleValues: ["5.5","5.4"] # New field

variableDefaults:
  - name: "VERSION"
     value: "5.5"

Describe alternatives you've considered
Alternatives include parsing the raw draft templates in their yaml formats, or creating a second source of truth for this information.

Since one of the core value-adds of draft is its single-binary install that leverages embedded file systems and its focus on extensibility, these alternatives are less in line with the overall project vision.

Additional context

update integration-info test to ensure our json output maintains a strong contract

Enhance the `draft info` output

Is your feature request related to a problem? Please describe.

It would be really nice if the info command could provide enough information to build an experience like that of the Azure Portal:
image

In the above, selection of a language version allows consumers to infer both runtime and builder images, as well as a default port.

Mention what platform you want to support the new feature

All

Describe the solution you'd like

Currently, Draft outputs this (to take Java as an example):

    {
      "name": "java",
      "displayName": "Java",
      "variableExampleValues": {
        "BUILDERVERSION": [
          "3-jdk-11"
        ],
        "VERSION": [
          "8-jre",
          "11-jre",
          "17-jre",
          "19-jre"
        ]
      }

But an Azure Portal-like experience would require something like this:

{
    "name": "java",
    "displayName": "Java",
    "defaultPort": 8080,
    "versions": [
        {
            "name": "Java 8",
            "imageVersion": "8-jre",
            "builderVersion": "3-eclipse-temurin-8"
        },
        {
            "name": "Java 11",
            "imageVersion": "11-jre",
            "builderVersion": "3-eclipse-temurin-11"
        },
        {
            "name": "Java 17",
            "imageVersion": "17-jre",
            "builderVersion": "3-eclipse-temurin-17"
        },
        {
            "name": "Java 19",
            "imageVersion": "19-jre",
            "builderVersion": "3-eclipse-temurin-19"
        },
    ]
}

I.e. in addition to the current output, it would also allow consumers to extract:

  • A display name for each of the versions
  • An image version for each of the versions
  • A builder version for each of the versions (if required in the Dockerfile)
  • A default port for the language
  • A more comprehensive selection of versions (e.g. for go, the info command outputs 1.16..1.19, yet the Portal displays 1.15..1.20)

Describe alternatives you've considered

As a consumer of Draft, I can maintain my own JSON mapping of languages to versions and ports, just as the Portal has to.

Additional context

I understand that maintaining a list of available versions (and associated images for each) is a maintenance overhead, but if Draft doesn't do that then consuming tools all have to, meaning it's hard to keep them in sync.

Draft Create Auto Detect pom.xml file during Java detection

Is your feature request related to a problem? Please describe.

When running draft create on the following folder https://github.com/buildpacks/samples/blob/main/apps/java-maven/, draft shows the following prompt:

[Draft] --- Detecting Language ---
Use the arrow keys to navigate: ↓ ↑ → ←
? Linguist detected Java, are you using maven or gradle?:
    gradle
  > maven

Mention what platform you want to support the new feature

OSS draft

Describe the solution you'd like

Draft should detect that maven is being used by seeing the pom.xml file in the repository.

Describe alternatives you've considered

There may be a better way to detect maven.

Additional context

(none)

What do you like about Draft? Does it help you accomplish your goals?

Hey everyone!

It has been a couple months since the preview of Draft has been released, we would love to hear from you! A couple of questions we have are.

What do you like about Draft?

Does Draft help you in your day to day life as a developer?

What would you like to see be added to Draft?

Thanks!
The Draft Team

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.