A tool to build, deploy, and release any application on any platform.

Image


Waypoint

Waypoint allows developers to define their application build, deploy, and release lifecycle as code, reducing the time to deliver deployments through a consistent and repeatable workflow.

Waypoint supports a number of build methods and target platforms out of the box and more can be easily added via plugins:

  • Cloud Native Buildpacks
  • Docker
  • Kubernetes
  • AWS EC2 and ECS
  • Azure Container Instances
  • Google Cloud Run
  • Netlify
  • And many more...

Waypoint runs on Linux, Mac OS X, and Windows.

Please note: We take Waypoint's security and our users' trust very seriously. If you believe you have found a security issue in Waypoint, please responsibly disclose by contacting us at [email protected].

Quick Start

A few quick start guides are available on the Waypoint website and on HashiCorp Learn:

Documentation

Full, comprehensive documentation is available on the Waypoint website:

https://www.waypointproject.io/docs

Contributing

Thank you for your interest in contributing! Please refer to CONTRIBUTING.md for guidance.

Installing Dependencies

This repository contains a couple of different ways to automate installing the required Golang packages needed to build Waypoint locally. You can either use NixOS, or run make tools to setup the required packages.

Running the unit tests

To run the entire test suite, you'll want to ensure that you've brought up all the required containers used for testing. You can do this by leveraging the existing docker-compose.yml file that's in the root directory of this project:

$ docker-compose up

After running this, you should have a local Horizon container along with a few other services needed for running the tests:

$ make test

Running individual tests

If you don't want to run the entire test suite, you can just run a singe test with go. For example, if you wanted to run the tests ListInstances, you would run:

$ go test -run ListInstances -v ./internal/server/singleprocess
Owner
HashiCorp
Consistent workflows to provision, secure, connect, and run any infrastructure for any application.
HashiCorp
Comments
  • tests/Frontend/ember-build-tests: Unhandled error event

    tests/Frontend/ember-build-tests: Unhandled error event

    Describe the bug

    The ember build frontend tests seem to be failing often. I think this test specifically has failed for me about ~5 times today.

    https://app.circleci.com/pipelines/github/hashicorp/waypoint/9896/workflows/0f6d5e84-1e59-47ef-9916-75f8f0d22a36/jobs/87707

    WARNING: Detected collisions between .js and .ts files of the same name. This can result in nondeterministic build output; see https://git.io/JvIwo for more information.
      - waypoint/services/flash-messages.{js,ts}
    [BABEL] Note: The code generator has deoptimised the styling of /home/circleci/project/ui/node_modules/axe-core/axe.js as it exceeds the max of 500KB.
    [BABEL] Note: The code generator has deoptimised the styling of /home/circleci/project/ui/node_modules/waypoint-pb/server_pb.js as it exceeds the max of 500KB.
    events.js:291
          throw er; // Unhandled 'error' event
          ^
    
    Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed
        at ChildProcess.target.send (internal/child_process.js:680:16)
        at Object.sendMessage (/home/circleci/project/ui/node_modules/stagehand/lib/adapters/child-process.js:30:39)
        at CommandCoordinator.sendMessage (/home/circleci/project/ui/node_modules/stagehand/lib/command-coordinator.js:81:23)
        at CommandCoordinator.sendCommand (/home/circleci/project/ui/node_modules/stagehand/lib/command-coordinator.js:36:14)
        at Stagehand.<anonymous> (/home/circleci/project/ui/node_modules/stagehand/lib/stagehand.js:86:44)
        at Generator.next (<anonymous>)
        at /home/circleci/project/ui/node_modules/stagehand/lib/stagehand.js:7:71
        at new Promise (<anonymous>)
        at __awaiter (/home/circleci/project/ui/node_modules/stagehand/lib/stagehand.js:3:12)
        at Stagehand.call (/home/circleci/project/ui/node_modules/stagehand/lib/stagehand.js:82:16)
    Emitted 'error' event on ChildProcess instance at:
        at internal/child_process.js:684:35
        at processTicksAndRejections (internal/process/task_queues.js:79:11) {
      code: 'ERR_IPC_CHANNEL_CLOSED'
    }
    error Command failed with exit code 1.
    info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command
    

    Steps to Reproduce

    The tests flake occasionally on PRs and commits to main.

    Expected behavior

    They pass.

    Waypoint Platform Versions

    N/A

    Additional context Add any other context about the problem here.

  • ! Error initializing server: context deadline exceeded

    ! Error initializing server: context deadline exceeded

    Describe the bug Waypoint for docker is crashing with this error

    Steps to Reproduce Steps to reproduce the behavior. Please include any waypoint.hcl files if applicable.

    Expected behavior A clear and concise description of what you expected to happen.

    Additional context Add any other context about the problem here.

    020-10-15T21:17:13.037Z [INFO] waypoint: waypoint version: full_string="Waypoint v0.1.1 (44e2d3d6+CHANGES)" version=v0.1.1 prerelease= metadata= revision=44e2d3d6+CHANGES
    
    2020-10-15T21:17:13.037Z [TRACE] waypoint: starting interrupt listener for context cancellation
    
    2020-10-15T21:17:13.038Z [TRACE] waypoint: interrupt listener goroutine started
    
    2020-10-15T21:17:13.038Z [DEBUG] waypoint: home configuration directory: path=/home/waypoint/.config/waypoint
    
    2020-10-15T21:17:13.038Z [INFO] waypoint.server: opening DB: path=/data/data.db
    
    2020-10-15T21:17:23.009Z [INFO] waypoint.server: gracefully closing db: path=/data/data.db
    
    2020-10-15T21:17:23.009Z [TRACE] waypoint: stopping signal listeners and cancelling the context
    
    ! Error initializing server: context deadline exceeded
    
  • feat: add deployment URL

    feat: add deployment URL

    This PR, which has https://github.com/hashicorp/waypoint-plugin-sdk/pull/27 as a pre-requisite, adds support for Deployment URLs.

    With this PR, it is now possible to show in the CLI the deployment URLs provided by the plugins, without the need of Horizon (URL Service).

    Warning: The PR contains a go.mod entry that points to our fork since the PR in https://github.com/hashicorp/waypoint-plugin-sdk hasn't been merged yet.

  • Waypoint not deploying in private nomad cluster

    Waypoint not deploying in private nomad cluster

    Describe the bug waypoint not intializing in nomad cluster

    Steps to Reproduce https://learn.hashicorp.com/tutorials/waypoint/get-started-nomad?in=waypoint/get-started-nomad waypoint init [email protected]: ~/waypoint-examples/nomad/nodejs# waypoint install -platform=nomad --nomad-dc=nomad -accept-tos ❌ Nomad allocation created ! Error installing server into Nomad: allocation failed

    Expected behavior it should deploy in nomad cluster.

    image

  • Couldn't find a Waypoint deployment with this URL

    Couldn't find a Waypoint deployment with this URL

    Describe the bug After running the following command waypoint up could see in the console output

    Deployment URL: https://globally-helping-haddock--v4.waypoint.run

    but, when opening the url in a browser tab getting the error Couldn't find a Waypoint deployment with this URL

    Also, please find attache the snapshot of the error.

    image

    Steps to Reproduce Follow the exact steps mentioned in the Getting Started guide https://www.waypointproject.io/docs/getting-started After running the command waypoint up i could see the below response on the console.

    
    » Building...
    Creating new buildpack-based image using builder: heroku/buildpacks:18
     + Creating pack client
     + Building image
     │ [exporter] Adding 1/1 app layer(s)
     │ [exporter] Adding layer 'launcher'
     │ [exporter] Adding layer 'config'
     │ [exporter] Adding label 'io.buildpacks.lifecycle.metadata'
     │ [exporter] Adding label 'io.buildpacks.build.metadata'
     │ [exporter] Adding label 'io.buildpacks.project.metadata'
     │ [exporter] *** Images (ebe25a8c6faa):
     │ [exporter]       index.docker.io/library/example-nodejs:latest
     │ [exporter] Reusing cache layer 'heroku/nodejs-engine:nodejs'
     │ [exporter] Reusing cache layer 'heroku/nodejs-engine:toolbox'
     + Injecting entrypoint binary to image
    
    Generated new Docker image: example-nodejs:latest
    
    » Deploying...
     + Setting up waypoint network
     + Starting container
     + App deployed as container: example-nodejs-01EMR1KCKSCCEZBFY72S2F9MA8
    
    » Releasing...
    
    » Pruning old deployments...
      Deployment: 01EMQXFT1WH5C1NC6TDG17KHPH
    
    The deploy was successful! A Waypoint deployment URL is shown below. This
    can be used internally to check your deployment and is not meant for external
    traffic. You can manage this hostname using "waypoint hostname."
    
               URL: https://globally-helping-haddock.waypoint.run
    Deployment URL: https://globally-helping-haddock--v4.waypoint.run
    

    Expected behavior Should be able to see the url with demo content

    Additional context

  • Waypoint UI losing application.log history after changing tabs

    Waypoint UI losing application.log history after changing tabs

    I noticed that after application startup when following the application.log in the UI, if i switch to another tab in the ui, ie Builds or Deployments and then go back to the Logs tab immediately the log history is lost. I no longer see the logs from my application startup. But instead i see the following two lines:

    2020-12-17T13:09:15+01:00: [ERROR] entrypoint.log: log stream disconnected from server, attempting reconnect: err=EOF
    2020-12-17T13:08:53+01:00: [ERROR] entrypoint.log: log stream disconnected from server, attempting reconnect: err=EOF
    

    For debugging purposes i've also attached an image of how it looks before i switch tabs:

    wp_ui

    It should also be mentioned that these entrypoint.log errors where non existant on WP version 0.1.5. For the record, we have been running on AWS Fargate all the time.

  • Waypoint failed to install on DigitalOcean Kubernetes

    Waypoint failed to install on DigitalOcean Kubernetes

    Describe the bug

    I tried to install Waypoint on a Kubernetes cluster created on DigitalOcean by following the instructions on HashiCorp Learn and was met with this error:

    ❯ waypoint install --platform=kubernetes -accept-tos
    ✓ Creating Kubernetes resources...
     │ service/waypoint created
     │ statefulset.apps/waypoint-server created
    ✓ Kubernetes StatefulSet reporting ready
    ✓ Waiting for Kubernetes service to become ready..
    ❌ Connecting to: 206.189.254.81:9701
    ! Error connecting to server: context deadline exceeded
    
      The Waypoint server has been deployed, but due to this error we were
      unable to automatically configure the local CLI or the Waypoint server
      advertise address. You must do this manually using "waypoint context"
      and "waypoint server config-set".
    

    The Waypoint Server is in CrashLoopBackOff:

    ❯ kubectl get po waypoint-server-0
    NAME                READY   STATUS             RESTARTS   AGE
    waypoint-server-0   0/1     CrashLoopBackOff   6          7m39s
    

    And the logs indicate a permission issue when opening the database:

    ❯ kubectl logs waypoint-server-0
    2020-10-29T23:49:41.781Z [INFO]  waypoint: waypoint version: full_string="Waypoint v0.1.4 (3810a3c7+CHANGES)" version=v0.1.4 prerelease= metadata= revision=3810a3c7+CHANGES
    2020-10-29T23:49:41.781Z [TRACE] waypoint: starting interrupt listener for context cancellation
    2020-10-29T23:49:41.782Z [DEBUG] waypoint: home configuration directory: path=/home/waypoint/.config/waypoint
    2020-10-29T23:49:41.782Z [INFO]  waypoint.server: opening DB: path=/data/data.db
    2020-10-29T23:49:41.782Z [TRACE] waypoint: stopping signal listeners and cancelling the context
    ! Error opening database: open /data/data.db: permission denied
    2020-10-29T23:49:41.782Z [TRACE] waypoint: interrupt listener goroutine started
    

    Steps to Reproduce

    1. Create a Kubernetes cluster on DigitalOcean.
    2. Add the kubeconfig locally via doctl.
    3. Run waypoint install --platform=kubernetes -accept-tos

    Expected behavior

    That the Waypoint Server runs.

    Additional context

    The Kubernetes version is 1.19.3-do.0.

  • failed to create client: context deadline exceeded

    failed to create client: context deadline exceeded

    Describe the bug

    Every operation with waypoint cli results in failed to create client: context deadline exceeded.

    Steps to Reproduce Steps to reproduce the behavior. Please include any waypoint.hcl files if applicable.

    i have multipass based ubuntu 20.04 vm, initially everything worked. k3s is installed and waypoint server components are installed.

    kubectl get all
    NAME                       READY   STATUS    RESTARTS   AGE
    pod/waypoint-server-0      1/1     Running   2          160m
    pod/svclb-waypoint-tfzps   2/2     Running   2          160m
    
    NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                         AGE
    service/kubernetes   ClusterIP      10.43.0.1       <none>         443/TCP                         3h39m
    service/waypoint     LoadBalancer   10.43.141.177   172.20.20.45   9701:31813/TCP,9702:32692/TCP   160m
    
    NAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/svclb-waypoint   1         1         1       1            1           <none>          160m
    
    NAME                               READY   AGE
    statefulset.apps/waypoint-server   1/1     160m
    

    After restart, vm ip has been changed and now every waypoint cli invoke results in failed to create client: context deadline exceeded. waypoint web ui is also available but not able to interact with the server. Any option to reset client to regenerate token etc as even not able to regenerate token as well with waypoint token new

    Thanks

  • [WIP] builtin/aws: graceful destroy of ALB/Lambda target group

    [WIP] builtin/aws: graceful destroy of ALB/Lambda target group

    This ensures that ALB-related resources get destroyed properly during Lambda teardown by:

    • Adding Destroyer to the ALB releaser.
    • Adding a rudimentary waiter to the target group removal in the Lambda destroyer.

    The latter ensures that the target group can be removed successfully as in addition to removing the dependent ALB as it can take a moment for the ALB removal/detachment to fully register.

  • Node port parameter is not supported using kubernetes plugin

    Node port parameter is not supported using kubernetes plugin

    Issue

    The following hcl config which includes the node_port parameter to configure the kubernetes k8s resource as mentioned within the doc - https://www.waypointproject.io/plugins/kubernetes is not supported

    hcl config

    project = "example-java"
    
    app "example-java" {
        build {
            use "pack" {
                builder="gcr.io/buildpacks/builder:v1"
            }
            registry {
                  use "docker" {
                    image = "localhost:5000/example-java"
                    tag   = "latest"
                    local = true
                  }
                }
        }
    
        deploy {
          use "kubernetes" {
            namespace = "demo"
            probe_path = "/"
            service_port = 8080
            node_port = 32000
          }
        }
    
        release {
          use "kubernetes" {
          }
        }
    }
    

    Error

    waypoint deploy 
    
    » Deploying...
    ! /Users/cmoullia/temp/waypoint/waypoint-examples/docker/java/waypoint.hcl:22,9-18:
      Unsupported argument; An argument named "node_port" is not expected here.
    
    
  • Feat/docker auth

    Feat/docker auth

    Fixes #2577.

    Uses AuthConfig type from Docker's Go API in order to authenticate to a private registry when an image is built. This is required if a base image is from a private repo.

    Example build stanza with username/password auth configured:

      build {
        use "docker" {
          auth {
            hostname       = "registry.hub.docker.com"
            username       = "dockeruser"
            password       = "dockerpass"
          }
        }
      }
    

    All of the following parameters are supported (map of string):

            hostname      = ""
            username      = ""
            password      = ""
            email         = ""
            auth          = ""
            serverAddress = ""
            identityToken = ""
            registryToken = ""
    
  • Make Registry Stanza required for Build

    Make Registry Stanza required for Build

    Describe the bug

    If a user tries Waypoint with a remote project backed by git, they often run into a situation where they get a huge arg-mapper error saying they're missing docker.AccessInfo. This is because in a remote context, we require a registry so that Kaniko can push the built artifact outside of the container it was built in.

    Given that remote projects are our general suggestion for using Waypoint, we should flip this behavior. Instead, we should make a registry stanza required, which is the happy path, and require that folks opt-out of using it if they so choose and want to use the docker plugin and push locally.

    Steps to Reproduce

    https://github.com/hashicorp/waypoint/issues/3314

    Run a Waypoint project in a remote context without a registry stanza.

    Expected behavior

    Users should get feedback that they are missing a required stanza registry before they get to the point that waypoint is trying to build their project.

    Waypoint Platform Versions

    Any

    Additional context Add any other context about the problem here.

  • test: Automatically run all tests rather than require them to be registered

    test: Automatically run all tests rather than require them to be registered

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

    When writing new state and now service tests, we require people to "register" their test functions, otherwise go test will not run them and they will be skipped.

    https://github.com/hashicorp/waypoint/blob/14e47e4eb16729e1433cf13b6b7e764fb6d5f164/pkg/serverstate/statetest/test_job.go#L20-L33

    This is not 100% ideal, because it's easy to write new tests and assume that they will be run, which is generally how other tests work. There's no feedback on if the new test func was skipped or run at all, making it easy to think that it's just "passing".

    Describe the solution you'd like

    Rather than requiring that we register test funcs in an init(), we should just automatically run the tests defined inside the test file.

    Describe alternatives you've considered

    Big warnings if a test was defined but not registered in init()?

  • internal/core: Introduce `pipeline` and `step` parsing and validation for HCL config

    internal/core: Introduce `pipeline` and `step` parsing and validation for HCL config

    This pull request implements an internal config parser and validation func for loading pipeline and its step stanzas for a waypoint.hcl config.

    There are a few TODOs for how we intend to load Step Use labels and plugin names for plugin execution. These are left as-is for now with some comments, because this PR does not handle Step plugin execution. This will be covered in future PRs.

  • Pipeline Step Execution

    Pipeline Step Execution

    This PR adds a new job operation to execute a single pipeline step.

    This only supports exec steps at the moment, which are just arbitrary Docker images that have no access to the application source. We're starting with exec steps through the whole system, and will layer on additional functionality once it is minimally working.

    The primary introduction in this PR is the "task override" in the job and the ability to "skip operation" (see protobuf comments). This allows us to utilize the ODR system to run our custom Docker images and inherit all the functionality around that such as runner profiles, job log streaming, dependencies, and more.

    This "task override" system is essentially remote code execution, but that already exists in the form of runner profiles, hooks, and more -- so long as you have a Waypoint token. As we introduce more tightly controlled ACLs in the future, we can better control this.

  • CLI deploy/deployment destroy deletes job in Nomad

    CLI deploy/deployment destroy deletes job in Nomad

    When I invoke waypoint deploy (it destroys old deployments during the release phase) or waypoint deployment destroy then it also deletes the job in Nomad:

    image

    Steps to Reproduce

    1. waypoint deployment list image

    2. job tim is properly running in Nomad

    3. waypoint deployment destroy 267

    4. job tim is deleted image

    Waypoint Platform Versions

    • Waypoint CLI Version: 0.8.1
    • Waypoint Server Platform and Version: Nomad 0.8.1
    • Waypoint Plugin: nomad-jobspec
  • Error when project linked to git

    Error when project linked to git

    Describe the bug when git is linked to a project build is failing with error:

    ! There was an error while executing a Waypoint plugin for this operation!
    
      One or more required arguments for the plugin was not satisfied. This is usually
      due to a missing or incompatible set of plugins. For example, only certain build
      plugins are only compatible with certain registries, and so on. Please inspect
      the missing argument, the set of plugins you are using, and the documentation to
      determine if your plugin combination is valid.
    
      Plugin function:
      github.com/hashicorp/waypoint/builtin/pack.(*Builder).BuildODR-fm
    
      ==> Missing arguments:
    
          - docker.AccessInfo
    

    Steps to Reproduce

    • Fresh Ubuntu installation with docker
    • install waypoint package
    • install waypoint service waypoint install -platform=docker -accept-tos
    • add GIT repo via UI
    • run build
    project = "test"
    
    app "web" {
        build {
            use "pack" {
                builder     = "heroku/buildpacks:20"
                disable_entrypoint = false
            }
        }
    
        deploy {
            use "docker" {}
        }
    }
    

    Expected behavior Build does not fail. project build is passed if no git added

    Waypoint Platform Versions waypoint -v CLI: v0.8.1 (622f37bd1) Server: v0.8.1

    Docker version 20.10.14, build a224086

Natural-deploy - A natural and simple way to deploy workloads or anything on other machines.

Natural Deploy Its Go way of doing Ansibles: Motivation: Have you ever felt when using ansible or any declarative type of program that is used for dep

Jan 3, 2022
Bubbly is an open-source platform that gives you confidence in your continuous release process.
Bubbly is an open-source platform that gives you confidence in your continuous release process.

Bubbly Bubbly - Release Readiness in a Bubble Bubbly emerged from a need that many lean software teams practicing Continuous Integration and Delivery

Apr 22, 2022
Sqedule — a release auditing & approval platform

Sqedule — a release auditing & approval platform Sqedule is an application release auditing & approval platform. Auditing: Sqedule allows teams to hav

Mar 13, 2022
A simple Go app and GitHub workflow that shows how to use GitHub Actions to test, build and deploy a Go app to Docker Hub

go-pipeline-demo A repository containing a simple Go app and GitHub workflow that shows how to use GitHub Actions to test, build and deploy a Go app t

Nov 17, 2021
Build and deploy Go applications on Kubernetes
Build and deploy Go applications on Kubernetes

ko: Easy Go Containers ko is a simple, fast container image builder for Go applications. It's ideal for use cases where your image contains a single G

May 6, 2022
Use Terraform to build and deploy configurations for Juniper SRX firewalls.
Use Terraform to build and deploy configurations for Juniper SRX firewalls.

Juniper Terraform - SRX Overview The goal of this project is to provide an example method to interact with Juniper SRX products with Terraform. ?? Ter

Mar 16, 2022
A Go based deployment tool that allows the users to deploy the web application on the server using SSH information and pem file.

A Go based deployment tool that allows the users to deploy the web application on the server using SSH information and pem file. This application is intend for non tecnhincal users they can just open the GUI and given the server details just deploy.

Oct 16, 2021
Christmas Hack Day Project: Build an Kubernetes Operator to deploy Camunda Cloud services

Camunda Cloud Operator Christmas Hack Day Project (2021): Build an Kubernetes Operator to deploy Camunda Cloud services Motiviation / Idea We currentl

Dec 19, 2021
Koyeb is a developer-friendly serverless platform to deploy apps globally.
Koyeb is a developer-friendly serverless platform to deploy apps globally.

Koyeb Serverless Platform Deploy a Go Gin application on Koyeb Learn more about Koyeb · Explore the documentation · Discover our tutorials About Koyeb

Feb 7, 2022
cloud native application deploy flow
cloud native application deploy flow

Triton-io/Triton English | 简体中文 Introduction Triton provides a cloud-native DeployFlow, which is safe, controllable, and policy-rich. For more introdu

Apr 6, 2022
General-purpose actions for test and release in Go

go-actions This repository provides general-purpose actions for Go. setup This action runs actions/setup-go with actions/cache. For example, jobs: l

Nov 28, 2021
A helm v3 plugin to get values from a previous release

helm-val helm-val is a helm plugin to fetch values from a previous release. Getting started Installation To install the plugin: $ helm plugin install

Feb 8, 2022
API for managing the release calendar

dp-release-calendar-api API for managing the release calendar Getting started Run make debug Dependencies No further dependencies other than those def

Feb 10, 2022
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration, and automating updates to configuration when there is new code to deploy.
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration, and automating updates to configuration when there is new code to deploy.

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.

May 8, 2022
Deploy, manage, and secure applications and resources across multiple clusters using CloudFormation and Shipa

CloudFormation provider Deploy, secure, and manage applications across multiple clusters using CloudFormation and Shipa. Development environment setup

Feb 12, 2022
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.

May 11, 2022
Small and easy server for web-hooks to deploy software on push from gitlab/github/hg and so on

Deployment mini-service This mini web-server is made to deploy your code without yaml-files headache. If you just need to update your code somewhere a

Aug 31, 2021
`runenv` create gcloud run deploy `--set-env-vars=` option and export shell environment from yaml file.

runenv runenv create gcloud run deploy --set-env-vars= option and export shell environment from yaml file. Motivation I want to manage Cloud Run envir

Feb 10, 2022
Automatically deploy from GitHub to Replit, lightning fast ⚡️

repl.deploy Automatically deploy from GitHub to Replit, lightning fast ⚡️ repl.deploy is split into A GitHub app, which listens for code changes and s

Apr 26, 2022