DEV Community: Oscar Nevárez

Asciinema actions

Oscar Nevárez — Tue, 30 Nov 2021 15:42:56 +0000

My Workflow

So I had this idea of turning code blocks within markdown files into gifs. That's what this Github Action does :D!

Introducing action

Turns this

#Here we go!
npm i -g @org/awesome-project

into this

Usage

There are actually two actions working here.

1) asccicast parses a mardown file and produces description files that helps to traverse its content.

2) asciicast2gif use json files produced by asccicast and turn them into GIF files. this action also accepts JSON files from asciinema.org

Here's a online demo


name: ci

on:
  push:
    branches: [ 'dev' ]

jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      - name: Asccinema generation
        id: asccinema
        uses: oscarnevarezleal/asciinema-actions/actions/asccicast@dev
        with:
          args: generate -s README.template.md -o README.md
          config: .asciinema.json
      - name: Theme block 0
        uses: oscarnevarezleal/asciinema-actions/actions/asciicast2gif@dev
        with:
          theme: tango
          rows: 5
          scale: 1
          files: "block-0.*"
      - name: Theme block 1
        uses: oscarnevarezleal/asciinema-actions/actions/asciicast2gif@dev
        with:
          theme: solarized-dark
          rows: 3
          scale: 1
          files: "block-1.*"
      - name: Theme block 2
        uses: oscarnevarezleal/asciinema-actions/actions/asciicast2gif@dev
        with:
          theme: monokai
          rows: 3
          scale: 1
          files: "block-2.*"
      - uses: stefanzweifel/git-auto-commit-action@v4
        with:
          # Optional, but recommended
          # Defaults to "Apply automatic changes"
          commit_message: Automated Change

          # Optional. Used by `git-commit`.
          # See https://git-scm.com/docs/git-commit#_options
          commit_options: '--no-verify --signoff'

          # Optional glob pattern of files which should be added to the commit
          # Defaults to all (.)
          # See the `pathspec`-documentation for git
          # - https://git-scm.com/docs/git-add#Documentation/git-add.txt-ltpathspecgt82308203
          # - https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec
          file_pattern: ".asciicast/*.gif *.md"

My recomended workflow is to keep a markdown template ( the one containing the code fences ) e.g README.template.md so the final process results in a modified version of that file > README.md. Keeping both files in the repository will guarantee consistency and prevent any content missmatch.

Submission Category:

Maintainer Must-Haves / Wacky Wildcards

Yaml File or Link to Code

oscarnevarezleal / asciinema-actions

asccinema-action

View on GitHub

Additional Resources / Info

https://asciinema.org/

FORKS.md with GitHub Actions

Oscar Nevárez — Fri, 19 Nov 2021 17:30:22 +0000

My Workflow

Have you ever had a repository so loved by the community and you wonder which of the forks is more actively maintained than yours but there are hundreds of them already? [...] Yeah, me neither. But I know this is a common question with big open source projects.

This Github Action generates a FORKS.md file that keep track of all forks and, aditionally how far or behind are of the original project. Sweet indeed.

Submission Category:

Maintainer Must-Haves & DIY Deployments

Yaml File or Link to Code

oscarnevarezleal / vitraya-ramunong

The Tree of Souls (Na'vi name: Vitraya Ramunong [1]) is a giant willow tree that is said to be the closest connection to Eywa on Pandora

vitraya-ramunong

This Github Action generates or updates a FORK.md file to contain a list of all forks of a repository and, additionally how far or behind are they from upstream branch.

Check out the docs to know more.

                                                         .
                                              .         ;
                 .              .              ;%     ;;   
                   ,           ,                :;%  %;   
                    :         ;                   :;%;'     .,   
           ,.        %;     %;            ;        %;'    ,;
             ;       ;%;  %%;        ,     %;    ;%;    ,%'
              %;       %;%;      ,  ;       %;  ;%;   ,%;' 
               ;%;      %;        ;%;        % ;%;  ,%;'
                `%;.     ;%;     %;'         `;%%;.%;'
                 `:;%.    ;%%. %@;        %; ;@%;%'
                    `:%;.  :;bd%;          %;@%;'
                      `@%:.  :;%.         ;@@%;'   
                        `@%.  `;@%.      ;@@%;         
                          `@%%.

…

View on GitHub

Additional Resources / Info

Tech

Github Actions
GH CLI
Docker

Github actions

actions/checkout@v2

Headless CMS using Github Issues and Github Actions

Oscar Nevárez — Mon, 15 Nov 2021 05:04:35 +0000

My Workflow

Headless CMS using Hugo, Github Issues and Github Actions.

Every time a new issue is created, a new post is created as well.

main branch holds the content in markdown format. See content folder
gh-pages branch contains the distributable html site.

Submission Category:

Maintainer Must-Haves & DIY Deployments

Yaml File or Link to Code

oscarnevarezleal / gh-cms

Headless CMS using Github Issues and Github Actions

Gh-Cms

Headless CMS using Hugo, Github Issues and Github Actions.

How?

Every time a new issue is created, a new post is created as well.

Branch structure

main branch holds the content in markdown format. See content folder
gh-pages branch contains the distributable html site.

Bonus feature

Serve your content before publish it using ngrok.Take a look at .github/workflows/gh-serve.yml

Tech

Hugo
Github Actions

Github actions

actions/checkout@v2
peaceiris/actions-hugo@v2
stefanzweifel/git-auto-commit-action@v4
oscarnevarezleal/ngrok-tunneling-action@dev

View on GitHub

Additional Resources / Info

live demo

Create a new post by submitting a new issue

Tech

Hugo
Github Actions

Github actions

actions/checkout@v2
peaceiris/actions-hugo@v2
stefanzweifel/git-auto-commit-action@v4
oscarnevarezleal/ngrok-tunneling-action@dev

Issue Chill Action

Oscar Nevárez — Thu, 11 Nov 2021 18:57:51 +0000

My Workflow

oscarnevarezleal / issue-chill

Issue Chill Action

About

This action reads a GitHub Issue and outputs its Sentiment Analysis, so you can detect whether its content is redacted in a way that make it sound positive or negative.

Example

Create a .github/workflows/issue-sentiment.yml file in your repository with the following content Make sure to replace and with your repository values.

# .github/workflows/issue-sentiment.yml
name: Issue Sentiment Analysis
on:
  issues:
    types: [opened, edited]

jobs:  
  add-comment:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: Sentiment Analysis
        id: sa
        uses: oscarnevarezleal/issue-chill@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          owner: <org>
          repo: <repo>
          issue: ${{ github.event.issue.number }}

      - name: Add positive comment
        if: ${{ startsWith(steps.sa.outputs.IS_50_POS, 'true') }} # 60, 70, 80 and 90 also available
        uses: peter-evans/create-or-update-comment@a35cf36e5301d70b76f316e867e7788a55a31dae
        with:
          issue-number: ${{ github.event.issue.number }}
          body: |
            This issue

…

View on GitHub

Submission Category:

Maintaner Must-Haves

Yaml File or Link to Code

Usage

# .github/workflows/issue-sentiment.yml

name: Issue Sentiment Analysis
on:
  issues:
    types: [opened, edited]

jobs:  
  add-comment:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: Sentiment Analysis
        id: sa
        uses: oscarnevarezleal/issue-chill@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          owner: <org>
          repo: <repo>
          issue: ${{ github.event.issue.number }}

      - name: Add positive comment
        if: ${{ startsWith(steps.sa.outputs.IS_50_POS, 'true') }} # 60, 70, 80 and 90 also available
        uses: peter-evans/create-or-update-comment@a35cf36e5301d70b76f316e867e7788a55a31dae
        with:
          issue-number: ${{ github.event.issue.number }}
          body: |
            This issue is available for anyone to work on. **Make sure to reference this issue in your pull request.** :sparkles: Thank you for your contribution! :sparkles:

      - name: Add negative reaction
        if: ${{ startsWith(steps.sa.outputs.IS_70_NEG, 'true') }} # 50, 60, 70, 80 and 90 also available
        uses: peter-evans/create-or-update-comment@a35cf36e5301d70b76f316e867e7788a55a31dae
        with:
          issue-number: ${{ github.event.issue.number }}
          body: |
            Please refer to the Code Of Conduct.
            > "This Aggression Will Not Stand, Man."

Additional Resources / Info

Movie Maker

Oscar Nevárez — Thu, 11 Nov 2021 16:52:28 +0000

My Workflow

This project uses GithubActions to assemble a random movie clip every hour or so. Each of the frames is an image taken from the Unsplash Dataset.

The movie clip is available in the form of an artifact available in the release section.

There is no release history. The artifacts are replaced every time the workflow runs. Making the movie clip unique.

Submission Category:

Wacky Wildcards

Yaml File or Link to Code

oscarnevarezleal / movie-maker

Movie maker

# +---------------------------------+
# |                                 |
# +---------------------------------+
# |                                 |
# |             Action!             |
# |                                 |
# +---------------------------------+

About

This project uses GithubActions to assemble a random movie clip every hour or so. Each of the frames is an image taken from the Unsplash Dataset.

The movie clip is available in the form of an artifact available in the release section.

There is no release history.The artifacts are replaced every time the workflow runs. Making the movie clip unique.

This is a submission for the 2021 GitHub Actions Hackathon on DEV

Actions used

actions/checkout@v2
actions/cache@v2
FedericoCarboni/setup-ffmpeg@v1
actions/upload-artifact@v2
ncipollo/release-action@v1

Tech

View on GitHub

Additional Resources / Info

Actions used

actions/checkout@v2
actions/cache@v2
FedericoCarboni/setup-ffmpeg@v1
actions/upload-artifact@v2
ncipollo/release-action@v1

Tech

Create cloud-native buildpacks using Github Actions

Oscar Nevárez — Sun, 24 Oct 2021 19:07:36 +0000

I've been working with CNB technology a lot during the last few months particularly with pack and PackIt library. Overall it's been a lot of fun and learning along the way, I'm not going to lie here, the learning curve seemed propelled by a rocket but turned out to be quite simple once you grab your head around the new terminology and concepts . Just like anything in tech.

Once I understood the hows and whys then I was buildpacking this and buildpacking that, pretty soon I found myself doing repetitive jobs that were begging to be automized. I'm talking about simple script bundled into buildpacks for better distribution, organization, and versioning plus all the benefits CNB brings to the table.

I decided to invest some time in the making of a more generic tool to help me with this problem.

I needed a little something that took a list of commands and turn them into a valid build pack. In my mind, I could see and almost touch the form and shapes of this new toy, how the sequence of events was executed to coordinate the creation of this on the fly _buildpack.

Idea

The easiest way to explain the process is with the diagram below.

# From a working PackIt project, parametrize and map input commands 
# taken from a YML file
┌───────────────────────┐
│      Base file        │ 
└───────────────────────┘
          ▼
# Compile the modified project so once the build process kicks 
# https://buildpacks.io/docs/concepts/components/lifecycle/build/
# our buildpack executes one by one the **commands**
┌────────────────────────┐
│      Build.go          │ 
└────────────────────────┘
          ▼
# Pack it for distribution and release at will
┌────────────────────────┐
│    buildpack.cnb       │
└────────────────────────┘

Whiteboard time

What I first did was draft a very simple definition that allowed me to see how a regular user such as me, in this case, would like to define a list of commands. I decided to use YAML for this. Here's how a command file looks like.

This isn't a Github Action file although I borrowed some of the key names (name and run)

laraboot-commander:
  commands:
    - name: Init
      run: |
        echo "Init 🔥"
        pwd
    - name: NoOps
      run: |
        echo "Hello 🗺️"
        ls -ltah
    - name: Install deps
      run: |
        echo "installing 🤖"

This list could as well be defined as a list of "strings" but I foresee probably as a next step eventually I'd like to be able to pass extra parameters, environment variables, etc. Just like Github allows it. So the final definition looks something like the one below.

// type Commander struct {
//  WorkingDir string `yaml:"directory"`
//  Commands   []struct {
//      Name string `yaml:"name"`
//      Run  string `yaml:"run"`
//  } `yaml:"commands"`
// }

Then I thought, what would be the inputs I'd like to accept for the creation of buildpacks from Gh pov? That was a question easy to answer. Being familiar with pack cli I decided to ask just for name and version.

Detect

For the scope of the project, let's agree the detection will always occur and the buildpack will always participate in the build plan.

Build

The build part was quick because honestly executing a bash command or script in GO might be the easiest thing to do. Nevertheless, I found some blocks along the road that I didn't foresee in my planning.

Such as this one:

ERROR: failed to build: the launch, cache and build flags should be in the types table of /layers/xxx. Basically, if we're authoring a buildpack from a template then allowing the user to provide a name for it, the name provided has to be considered during the build process. We need to grab the name of a buildpack directly from the buildpack.toml file.

Also, the constant unknown of where I am stood (what context or path) and why it fails while running:

Locally
Locally with WSDL & ubuntu
Same repo remotely with Github actions
Another repository (consumer) using the Github action

At the end, I can say that for this being a quick prototype it actually works really good and might even be a more robust thing down the road.

Usage

Ok, how do we use this Github Action that creates buildpack for us? I'm glad you ask, couldn't be simpler.

First, create your commander file. It can contain several or just one command.

#commander.yml
laraboot-commander:
  commands:
    - name: Init
      run: |
        echo "Hello World"

As a part of my workflow I will use 3 actions:

The setup-pack action. This will set up pack cli and other util tools. Check out the repo if you feel interested.
Our commander action
actions/upload-artifact@v2

# .github/workflows/worklfow.yml
      - uses: buildpacks/github-actions/setup-pack@v4.1.0
        with:
          pack-version: 0.20.0

      - name: Gh action
        uses: laraboot-io/laraboot-commander/actions/commander@master
        with:
          name: my-buildpack
          version: 0.0.2
          file: commander.yml

      - name: Upload dist
        uses: actions/upload-artifact@v2
        with:
          name: dist
          path: dist

And if everything works fine it will look like this:

    'create'  buildpack.toml
    'create'  bin/build
    'create'  bin/detect
Successfully created 'my-buildpack'
Successfully created package 'dist/my-buildpack.cnb'

Then as a part of your workflow or in another project you might use this buildpack as follows:

mkdir -p app
pack build sample-app --path app --buildpack my-buildpack.cnb --builder cnbs/sample-builder:bionic

Conclusion

We've seen how to create a buildpack from a YML file using a custom GitHub action but the same can be replicated for any other CI runner easily.

We're going to hear more and more about buildpacks in the years to come. It's a game-changer for developers and operators in an era of automation and continuous integration. The source code of this post is available here

Where to go from here?

10 minute tutorial - Create and deploy a Laravel application using a low-code approach

Oscar Nevárez — Wed, 13 Oct 2021 16:38:18 +0000

Getting started

In this post, I want to show how quickly and easily Laraboot can help you create a solid start point for your next Laravel application including models, CRUD routes, and Jetstream integration. Best of all, we won't have to write any code.

Once we got the application ready we will use AWS ECR to deploy it.

Initialize and configure

Prerequisites

Make sure your system has the following requirements beforehand.

Docker desktop
NodeJs
AWS cli (for deployment only)

Install laraboot

Laraboot is installed through NPM. Check out the project here.

npm i -g @laraboot-io/cli

Create new project

laraboot new laraboot-demo-app --php-version=8 && cd laraboot-demo-app

Buildtasks

Build tasks are just custom buildpacks that create or modify a Laraboot project.

In this post, we're going to use several build tasks. If you feel adventurous, you can dive into the build task directory

The ones we require are:

We add them using laraboot cli like this

laraboot task add @core/laravel-foundation-provider --format=file
laraboot task add @core/laravel-config --format=file
laraboot task add @core/laravel-model --format=file
laraboot task add @core/laravel-starterkit-buildpack --format=file

Configure

Let's first create our data model. For the purpose of this post let's imagine we have 2 models. Post and Comment. We'll create them using the model command like this:

laraboot model add Post
√ Would you like to define your model now? (y/N) · true
√ Field name? · content
√ Field type? · varchar
√ Is this field unique? (y/N) · false
√ Is this field primary key? (y/N) · false
√ Would you like to add a new field? (y/N) · false
Model Post was added
laraboot model add Comment
√ Would you like to define your model now? (y/N) · true
√ Field name? · content
√ Field type? · varchar
√ Is this field unique? (y/N) · false
√ Is this field primary key? (y/N) · false
√ Would you like to add a new field? (y/N) · false
Model Comment was added

Then configure Jetstream. Add the following piece of content to the end of your buildpack.yml file

# buildpack.yml
laravel-starterkit:
  # Jetstream configuration
  jetstream:
    enabled: true
    teams: true
    stack: livewire
  # Breeze configuration
  breeze:
    enabled: false
    stack: inertia

Build

Once configured, kick the build process. Mind that the build time depends on your system capabilities and whether if this is the first time you build a laraboot project. Subsequent builds are significantly faster.

laraboot build

If everything goes as planned you should end up with an OCI-compliant image named laraboot-demo-app.

Preview

Let's see how everything looks like by running our application locally

laraboot run --port=9000

Awesomeness.

Deploy to AWS

Next, we're going to use AWS as a cloud provider and AWS ECR as the service registry but you can as well deploy to the CR of your preference.

Create an ECR repository using AWS cli

You can skip this part if you already have an AWS ECR repository.

There are two ways ( maybe more ) to create an ECR repository, in this post we'll use aws-cli.

# create an ecr repository
aws ecr create-repository \
    --repository-name laraboot-demo-app \
    --image-scanning-configuration scanOnPush=true

This will output something like this

{
    "repository": {
        "repositoryArn": "arn:aws:ecr:us-east-1:xxxxxxxxxxxx:repository/laraboot-demo-app",
        "registryId": "xxxxxxxxxxxx",
        "repositoryName": "laraboot-demo-app",
        "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/laraboot-demo-app",
        "createdAt": "2021-10-13T10:45:53-05:00",
        "imageTagMutability": "MUTABLE",
        "imageScanningConfiguration": {
            "scanOnPush": true
        },
        "encryptionConfiguration": {
            "encryptionType": "AES256"
        }
    }
}

Create an ECR repository through the AWS ECR console

You can achieve the same by signing into the AWS console and heading to the ECR service console management.

Click on Create repository
Fill out the blanks in the General settings panel
Click on Create repository

Deploy

The steps to deploy our image are the following

Sign in to the AWS ECR
Tag our image
Deploy


# replace xxxxxxxxxxxx with your AWS account id
# replace region if it's not us-east-1

# sign in to the ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com

## tag our image
docker tag laraboot-demo-app:latest xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/laraboot-demo-app:latest

## push
docker push xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/laraboot-demo-app:latest

Conclusion

On this occasion, we use Laraboot to set up a new Laravel application without having to write any line of code. This application has been containerized and deployed to AWS ECR in a matter of minutes.

Bootstrap a cloud-native Laravel application with Jetstream support

Oscar Nevárez — Tue, 12 Oct 2021 16:00:58 +0000

Preface

Laravel Jetstream is a starter kit for Laravel and provides a starting point for a Laravel application. Jetstream provides the implementation for the application's login, registration, email verification, two-factor authentication, session management, API via Laravel Sanctum, and optional team management features.

Although Laravel Jetstream requires NodeJS and PHP >= 8.0. On this occasion, we will bootstrap a Laravel application with Jetstream support using only laraboot CLI.

Install

We're going to need laraboot . Being an NPM CLI tool we're going to have to install it globally by running the npm install command.

npm i -g @laraboot-io/cli

Create a project

laraboot new app --php-version=8.0.* && cd app

Include required build tasks

Jetstream support is provided by the task @core/laravel-starterkit-buildpack. Let's add it to the mix and also add Paketo's NodeJs buildpack which take care of running all the npm command for us during the buildtime.

laraboot task add @core/laravel-starterkit-buildpack \
--format=file -vvv

laraboot task add nodejs \ 
--imageUri=gcr.io/paketo-buildpacks/nodejs \
--format=external \
--prepend \
-vvv

Configure

Buildtask configurations occur through the buildpack.yml file, should be already there in your project's root if the project was bootstrapped by laraboot. In case the file is not there we have to create it manually.

The following is the configuration we will use. We had disabled Breeze and enabled Jetstream.

# buildpack.yml
# Enable Jetstream teams with livewire
laravel-starterkit:
  # Jetstream configuration
  jetstream:
    enabled: true
    teams: true
    stack: livewire
  # Breeze configuration
  breeze:
    enabled: false
    stack: inertia

More information about the configuration of this task can be found here

Build

Build our custom Laravel application couldn't be easier than run the following command.

laraboot build -vvv

Run

After the build process is complete we end up with an OCI image called app which you can either run locally or deploy to the cloud using your favorite cloud provider.

laraboot run --port=9000

Source code

Absolutely? check it out at this repo

Cloud-native Laravel

Oscar Nevárez — Mon, 04 Oct 2021 17:02:06 +0000

What is Laraboot?

Laraboot is a CLI tool that allows Laravel developers to bootstrap and configure a Laravel application using cloud-native technologies which make your developer experience a lot more enjoyable.

Getting started

laraboot cli is distributed as a NPM project so make sure you have NodeJs installed then run:

npm i -g @laraboot-io/cli

Dependencies

We're also going to need Docker installed.

Create a new project

Similar to the Laravel installer you can run laraboot new to initialize a Laravel application.

laraboot new app --php-version=8.0 && cd app

Configure using core tasks

Laraboot has this task concept which resemble Heroku's buildpacks, the tasks participate during the build time allowing te construction of a Laravel application using a low-code approach.

Core tasks allow Laraboot to configure your Laravel application without writing any code.

Tip: you can run laraboot task search * --core-only to discover all the available core tasks.

We are going to use two of those tasks in this occasion model and config these tasks will help us to configure presicely those aspects of the framework.

# this first one is the foundation for other tasks.
laraboot task add @core/laravel-foundation-provider --format=file

laraboot task add @core/laravel-model --format=file
laraboot task add @core/laravel-config --format=file

Data model

Let's create some models, the most common of the examples I've seen in the Laravel forums involve a Post and a Comment.

laraboot model add Post
√ Would you like to define your model now? (y/N) · true
√ Field name? · content
√ Field type? · varchar
√ Is this field unique? (y/N) · false
√ Is this field primary key? (y/N) · false
√ Would you like to add a new field? (y/N) · false
Model **Post** was added

laraboot model add Comment
√ Would you like to define your model now? (y/N) · true
√ Field name? · content
√ Field type? · varchar
√ Is this field unique? (y/N) · false
√ Is this field primary key? (y/N) · false
√ Would you like to add a new field? (y/N) · false
Model **Comment** was added

This configuration is preserved in file laraboot.json and it will be read during the build process.

Configure our application

Something every Laravel developer is familiar with is the configuration of a new application. Laravel provides a simple file configuration system. Over time however, you may find yourself repeating the same exact configuration over and over again.

With Laraboot you only have to do it once, the configuration presset is stored in file and can be reused in another project.

Let's see how:

# Change the application name 
#  with a list of environment variables to look up for 
#  before using default value "App"

laraboot config set config.app/name App -e APP_NAME -e APPNAME

During the build process Laraboot will use @core/laravel-model task to automatically map every configuration set via CLI to Laravel config files.

In this case the file modified will be config/app.php.

Build

laraboot build

We’re ready to build the application. In this step, Laraboot will use the source code and will transform it using build tasks to finally create an OCI image. Please mind the process might take a while especially if this is the first time you run the build command.

If everything goes on without any problem you should have your Laravel project initialized with additional code generated especially for your project in the way you configure it.

What did just happened?

Under the hook Laraboot use laravel installer to initialize a new project
Using the configured tasks it configured your Laravel application
Each task used during the build process contribute to the final OCI image

Run

laraboot run --port=900

Boom! we have our application running. Head to http://localhost:9000 and you’ll see a familiar welcome page.

At this time you might figured it out already. Our OCI image is ready to be used, not to mention deployed. Images are named and tagged using your application name, in this case demo. Check it out

docker images

Conclusion

We used laraboot to create and configure a Laravel application using cloud-first principles. It tooks us some minutes to go from scratch to a custom state from which we can continue the development process as regular. Laraboot tasks are extremely useful to bootstrap a Laravel application, this time we only used two of them.