DBngin provides a free, all-in-one database management tool that includes MySQL, PostgreSQL, and Redis. After DBngin has been installed, you can connect to your database at 127.0.0.1 using the root username and an empty string for the password. $ brew update && brew install mycli # Only on macOS or $ sudo apt-get install mycli # Only on debian or ubuntu Usage $ mycli -help Usage: mycli OPTIONS DATABASE A MySQL terminal client with auto-completion and syntax highlighting. The new mysql@5.7 version 5.7.24 couldn't work because the some config reference was kept linked to the old mysql instead of the new brew Cellar mysql@5.7 Keg. So thanks I try this later – KeitelDOG Dec 28 '18 at 21:12.

The volumeMount is pretty self-explanatory—create a volume mount for the mariadb-config-volume (specified in the volumes list below it) to the path /etc/mysql/conf.d. Then, in the volumes list, configMap tells Kubernetes to use the mariadb-config ConfigMap, taking the contents of the key maxallowedpacket.cnf and mounting it to the path max. Git LFS Skip Smudge #. GitHub rate-limits the Git LFS requests during the git clone process. If you run into rate-limiting issues, you can skip fetching the git-lfs files during the initial git clone (equivalent to git lfs smudge -skip), and download these assets during the beforeinstall phase of your build.

• Installation
• Serving Sites
• Sharing Sites
• Custom Valet Drivers

Introduction

Valet is a Laravel development environment for macOS minimalists. Laravel Valet configures your Mac to always run Nginx in the background when your machine starts. Then, using DnsMasq, Valet proxies all requests on the *.test domain to point to sites installed on your local machine.

In other words, Valet is a blazing fast Laravel development environment that uses roughly 7 MB of RAM. Valet isn't a complete replacement for Sail or Homestead, but provides a great alternative if you want flexible basics, prefer extreme speed, or are working on a machine with a limited amount of RAM.

Out of the box, Valet support includes, but is not limited to:

• Static HTML

However, you may extend Valet with your own custom drivers.

Installation

{note} Valet requires macOS and Homebrew. Before installation, you should make sure that no other programs such as Apache or Nginx are binding to your local machine's port 80.

To get started, you first need to ensure that Homebrew is up to date using the update command:

Next, you should use Homebrew to install PHP:

After installing PHP, you are ready to install the Composer package manager. In addition, you should make sure the ~/.composer/vendor/bin directory is in your system's 'PATH'. After Composer has been installed, you may install Laravel Valet as a global Composer package:

Finally, you may execute Valet's install command. This will configure and install Valet and DnsMasq. In addition, the daemons Valet depends on will be configured to launch when your system starts:

Once Valet is installed, try pinging any *.test domain on your terminal using a command such as ping foobar.test. If Valet is installed correctly you should see this domain responding on 127.0.0.1.

Valet will automatically start its required services each time your machine boots.

PHP Versions

Valet allows you to switch PHP versions using the valet use [email protected] command. Valet will install the specified PHP version via Homebrew if it is not already installed:

{note} Valet only serves one PHP version at a time, even if you have multiple PHP versions installed.

Database

If your application needs a database, check out DBngin. DBngin provides a free, all-in-one database management tool that includes MySQL, PostgreSQL, and Redis. After DBngin has been installed, you can connect to your database at 127.0.0.1 using the root username and an empty string for the password.

Resetting Your Installation

If you are having trouble getting your Valet installation to run properly, executing the composer global update command followed by valet install will reset your installation and can solve a variety of problems. In rare cases, it may be necessary to 'hard reset' Valet by executing valet uninstall --force followed by valet install.

Upgrading Valet

You may update your Valet installation by executing the composer global update command in your terminal. After upgrading, it is good practice to run the valet install command so Valet can make additional upgrades to your configuration files if necessary.

Serving Sites

Once Valet is installed, you're ready to start serving your Laravel applications. Valet provides two commands to help you serve your applications: park and link.

The park Command

The park command registers a directory on your machine that contains your applications. Once the directory has been 'parked' with Valet, all of the directories within that directory will be accessible in your web browser at http://<directory-name>.test:

That's all there is to it. Now, any application you create within your 'parked' directory will automatically be served using the http://<directory-name>.test convention. So, if your parked directory contains a directory named 'laravel', the application within that directory will be accessible at http://laravel.test. In addition, Valet automatically allows you to access the site using wildcard subdomains (http://foo.laravel.test).

The link Command

The link command can also be used to serve your Laravel applications. This command is useful if you want to serve a single site in a directory and not the entire directory:

Once an application has been linked to Valet using the link command, you may access the application using its directory name. So, the site that was linked in the example above may be accessed at http://laravel.test. In addition, Valet automatically allows you to access the site using wildcard sub-domains (http://foo.laravel.test).

If you would like to serve the application at a different hostname, you may pass the hostname to the link command. For example, you may run the following command to make an application available at http://application.test:

You may execute the links command to display a list of all of your linked directories:

The unlink command may be used to destroy the symbolic link for a site:

Securing Sites With TLS

By default, Valet serves sites over HTTP. However, if you would like to serve a site over encrypted TLS using HTTP/2, you may use the secure command. For example, if your site is being served by Valet on the laravel.test domain, you should run the following command to secure it:

To 'unsecure' a site and revert back to serving its traffic over plain HTTP, use the unsecure command. Like the secure command, this command accepts the hostname that you wish to unsecure:

Sharing Sites

Valet even includes a command to share your local sites with the world, providing an easy way to test your site on mobile devices or share it with team members and clients.

Sharing Sites Via Ngrok

To share a site, navigate to the site's directory in your terminal and run Valet's share command. A publicly accessible URL will be inserted into your clipboard and is ready to paste directly into your browser or share with your team:

To stop sharing your site, you may press Control + C.

{tip} You may pass additional Ngrok parameters to the share command, such as valet share --region=eu. For more information, consult the ngrok documentation.

Sharing Sites Via Expose

If you have Expose installed, you can share your site by navigating to the site's directory in your terminal and running the expose command. Consult the Expose documentation for information regarding the additional command-line parameters it supports. After sharing the site, Expose will display the sharable URL that you may use on your other devices or amongst team members:

To stop sharing your site, you may press Control + C.

Sharing Sites On Your Local Network

Valet restricts incoming traffic to the internal 127.0.0.1 interface by default so that your development machine isn't exposed to security risks from the Internet.

If you wish to allow other devices on your local network to access the Valet sites on your machine via your machine's IP address (eg: 192.168.1.10/application.test), you will need to manually edit the appropriate Nginx configuration file for that site to remove the restriction on the listen directive. You should remove the 127.0.0.1: prefix on the listen directive for ports 80 and 443.

If you have not run valet secure on the project, you can open up network access for all non-HTTPS sites by editing the /usr/local/etc/nginx/valet/valet.conf file. However, if you're serving the project site over HTTPS (you have run valet secure for the site) then you should edit the ~/.config/valet/Nginx/app-name.test file.

Once you have updated your Nginx configuration, run the valet restart command to apply the configuration changes.

Site Specific Environment Variables

Some applications using other frameworks may depend on server environment variables but do not provide a way for those variables to be configured within your project. Valet allows you to configure site specific environment variables by adding a .valet-env.php file within the root of your project. This file should return an array of site / environment variable pairs which will be added to the global $_SERVER array for each site specified in the array:

Proxying Services

Sometimes you may wish to proxy a Valet domain to another service on your local machine. For example, you may occasionally need to run Valet while also running a separate site in Docker; however, Valet and Docker can't both bind to port 80 at the same time.

To solve this, you may use the proxy command to generate a proxy. For example, you may proxy all traffic from http://elasticsearch.test to http://127.0.0.1:9200:

You may remove a proxy using the unproxy command:

You may use the proxies command to list all site configurations that are proxied:

Custom Valet Drivers

Brew Mysql Config

You can write your own Valet 'driver' to serve PHP applications running on a framework or CMS that is not natively supported by Valet. When you install Valet, a ~/.config/valet/Drivers directory is created which contains a SampleValetDriver.php file. This file contains a sample driver implementation to demonstrate how to write a custom driver. Writing a driver only requires you to implement three methods: serves, isStaticFile, and frontControllerPath.

All three methods receive the $sitePath, $siteName, and $uri values as their arguments. The $sitePath is the fully qualified path to the site being served on your machine, such as /Users/Lisa/Sites/my-project. The $siteName is the 'host' / 'site name' portion of the domain (my-project). The $uri is the incoming request URI (/foo/bar).

Once you have completed your custom Valet driver, place it in the ~/.config/valet/Drivers directory using the FrameworkValetDriver.php naming convention. For example, if you are writing a custom valet driver for WordPress, your filename should be WordPressValetDriver.php.

Let's take a look at a sample implementation of each method your custom Valet driver should implement.

The serves Method

The serves method should return true if your driver should handle the incoming request. Otherwise, the method should return false. So, within this method, you should attempt to determine if the given $sitePath contains a project of the type you are trying to serve.

For example, let's imagine we are writing a WordPressValetDriver. Our serves method might look something like this:

The isStaticFile Method

The isStaticFile should determine if the incoming request is for a file that is 'static', such as an image or a stylesheet. If the file is static, the method should return the fully qualified path to the static file on disk. If the incoming request is not for a static file, the method should return false:

{note} The isStaticFile method will only be called if the serves method returns true for the incoming request and the request URI is not /.

The frontControllerPath Method

The frontControllerPath method should return the fully qualified path to your application's 'front controller', which is typically an 'index.php' file or equivalent:

Local Drivers

If you would like to define a custom Valet driver for a single application, create a LocalValetDriver.php file in the application's root directory. Your custom driver may extend the base ValetDriver class or extend an existing application specific driver such as the LaravelValetDriver:

Other Valet Commands

Valet Directories & Files

You may find the following directory and file information helpful while troubleshooting issues with your Valet environment:

~/.config/valet

Contains all of Valet's configuration. You may wish to maintain a backup of this directory.

~/.config/valet/dnsmasq.d/

This directory contains DNSMasq's configuration.

~/.config/valet/Drivers/

This directory contains Valet's drivers. Drivers determine how a particular framework / CMS is served.

~/.config/valet/Extensions/

This directory contains custom Valet extensions / commands.

~/.config/valet/Nginx/

This directory contains all of Valet's Nginx site configurations. These files are rebuilt when running the install, secure, and tld commands.

~/.config/valet/Sites/

This directory contains all of the symbolic links for your linked projects.

~/.config/valet/config.json

This file is Valet's master configuration file.

~/.config/valet/valet.sock

This file is the PHP-FPM socket used by Valet's Nginx installation. This will only exist if PHP is running properly.

~/.config/valet/Log/fpm-php.www.log

This file is the user log for PHP errors.

~/.config/valet/Log/nginx-error.log

This file is the user log for Nginx errors.

/usr/local/var/log/php-fpm.log

This file is the system log for PHP-FPM errors.

/usr/local/var/log/nginx

This directory contains the Nginx access and error logs.

/usr/local/etc/php/X.X/conf.d

This directory contains the *.ini files for various PHP configuration settings.

/usr/local/etc/php/X.X/php-fpm.d/valet-fpm.conf

This file is the PHP-FPM pool configuration file.

~/.composer/vendor/laravel/valet/cli/stubs/secure.valet.conf

This file is the default Nginx configuration used for building SSL certificates for your sites.

Travis CI Build Configuration and Settings #

Builds on Travis CI are configured mostly through the build configurationstored in the file .travis.yml in your repository. This allows yourconfiguration to be version controlled and flexible.

For advanced use cases the main build configuration file .travis.yml canimport other, shared config sources using the Build Config Importsfeature.

Detailed information about Travis CI’s build config format can be found in ourTravis CI Build Config Reference. Additionalinformation about Travis CI’s use of YAML as a language to describe buildconfiguration can be found here.

Other features can be controlled through the repository’s settings eitherthrough the Travis CI UI, or the Travis CI command line client.

Build Timeouts #

It is very common for test suites or build scripts to hang.Travis CI has specific time limits for each job, and will stop the build and add an error message to the build log in the following situations:

• When a job produces no log output for 10 minutes.
• When a job on a public repository takes longer than 50 minutes.
• When a job on a private repository takes longer than 120 minutes.

Some common reasons why builds might hang:

• Waiting for keyboard input or other kind of human interaction
• Concurrency issues (deadlocks, livelocks and so on)
• Installation of native extensions that take very long time to compile

There is no timeout for a build; a build will run as long as needed to complete all the jobs, but will stop immediately if any job hits a timeout limit.

Build Lifecycle #

The Build Lifecycle documentation now has its own page.

Limiting Concurrent Jobs #

The maximum number of concurrent jobs depends on the total system load, butone situation in which you might want to set a particular limit is:

• if your build depends on an external resource and might run into a racecondition with concurrent jobs.

You can set the maximum number of concurrent jobs in the settings pane foreach repository.

Or using the command line client:

Building Only the Latest Commit #

If you are only interested in building the most recent commit on each branch you can use this new feature to automatically cancel older builds in the queue that are not yet running. Existing builds will be allowed to finish.

The Auto Cancellation Setting is in the Settings tab of each repository, and you can enable it separately to:

• Auto cancel branch builds - cancels queued builds in your branch and appears in the Build History tab of your repository.

• Auto cancel pull request builds - cancels queued builds for pull requests (the future merge result of your change/feature branch against its target) and appears in the Pull Requests tab of your repository.

For example, in the following screenshot, we pushed commit ca31c2b to the branch MdA-fix-notice while builds #226 and #227 were queued. With the auto cancellation feature on, the builds #226 and #227 were automatically cancelled:

Git Clone Depth #

Travis CI can clone repositories to a maximum depth of 50 commits, which is only really useful if you are performing git operations.

Please note that if you use a depth of 1 and have a queue of jobs, Travis CI won’t build commits that are in the queue when you push a new commit.

You can set the clone depth in .travis.yml:

You can also remove the --depth flag entirely with:

Some operations on the repository, such as common automated code review scripts (e.g. Pronto for Ruby), may fail due to the limited git clone depth, not being able to access all the objects in the repository. Removing the depth flag, or running git fetch --unshallow might solve the issue.

Git Clone Quiet #

Travis CI clones repositories without the quiet flag (-q) by default. Enabling the quiet flag can be useful if you’re trying to avoid log file size limits or even if you just don’t need to include it.

You can enable the quiet flag in .travis.yml:

Git Submodules #

Travis CI clones Git submodules by default. To avoid this set:

Git LFS #

Authentication with GitHub #

We recommend using a read-only GitHub OAuth token to authenticate when using Git LFS:

This authentication is required when connecting to private repositories, and prevents rate-limiting when connecting to open source repositories.

Brew Mysql Setup

Deploy keys are not currently supported by LFS, so you should use a GitHub OAuth token to authenticate as in the example above.

Authentication with Bitbucket #

We recommend using a read-only Bitbucket OAuth token to authenticate when using Git LFS:

This authentication is required when connecting to private repositories, and prevents rate-limiting when connecting to open source repositories.

Deploy keys are not currently supported by LFS, so you should use a Bitbucket OAuth token to authenticate as in the example above.

Authentication with GitLab #

We recommend using a read-only GitLab OAuth token to authenticate when using Git LFS:

This authentication is required when connecting to private repositories, and prevents rate-limiting when connecting to open source repositories.

Deploy keys are not currently supported by LFS, so you should use a GitLab OAuth token to authenticate as in the example above.

Authentication with Assembla #

We recommend using a read-only Assembla OAuth token to authenticate when using Git LFS:

This authentication is required when connecting to private repositories, and prevents rate-limiting when connecting to open source repositories.

Deploy keys are not currently supported by LFS, so you should use a Assembla OAuth token to authenticate as in the example above.

Linux #

Git LFS is supported by default on our Ubuntu Trusty, Xenial and Bionic images.

macOS #

Installing git-lfs via brew is the recommended way to get Git LFS in macOS.

Git LFS Skip Smudge #

GitHub rate-limits the Git LFS requests during the git clone process. If you run into rate-limiting issues, you can skip fetching the git-lfs files during the initial git clone (equivalent to git lfs smudge --skip), and download these assets during the before_install phase of your build. To achieve this, you can use the following configuration in .travis.yml:

Git Sparse Checkout #

Travis CI supports git’s sparse checkoutcapability.

To clone your repository sparsely, add:

where skip-worktree-map-file is a path to the existing file in the current repository with data you’d like to put into $GIT_DIR/info/sparse-checkout file of format described in Git documentation.

Git End of Line Conversion Control #

Travis CI clones repositories with platform-dependent core.autocrlf behavior.This behavior can be modified via the autocrlf attribute in .travis.yml. Valid values are true, false and input.

To clone your repository without end of line conversion, add:

This is equivalent to git config --global core.autocrlf input prior to cloning the repository.

Disabling git clone #

In some workflows, like build stages, it might be beneficial to skip the automatic git clone step.

You can do this by adding:

Note that if you use this option, the TRAVIS_COMMIT_MESSAGE environment variable will not be defined.

Setting symlinks option #

In some cases when a repository is used for both Linux and Windows, it may be desirable to setcore.symlinks option.

To do this:

Building Specific Branches #

Travis CI uses the .travis.yml file from the branch containing the Git commit that triggers the build. Include branches using a safelist, or exclude them using a blocklist.

Note that you also need to take into account automatic Pull Request Builds when deciding to safelist or blocklist certain branches.

Safelisting or Blocklisting Branches #

Specify which branches to build using a safelist, or blocklist branches that you do not want to be built:

Note that safelisting also prevents tagged commits from being built. If you consistently tag your builds in the format v1.3 you can safelist them all with regular expressions, for example /^vd+.d+(.d+)?(-S*)?$/.

If you use both a safelist and a blocklist, the safelist takes precedence. By default, the gh-pages branch is not built unless you add it to the safelist.

To build all branches:

Note that for historical reasons .travis.yml needs to be present on all active branches of your project.

Using Regular Expressions #

You can use regular expressions to safelist or blocklist branches:

Any name surrounded with / in the list of branches is treated as a regular expression and can contain any quantifiers, anchors or character classes supported by Ruby regular expressions.

Options that are specified after the last / (e.g., i for case insensitive matching) are not supported but can be given inline instead. For example, /^(?i:deploy)-.*$/ matches Deploy-2014-06-01 and otherbranches and tags that start with deploy- in any combination of cases.

Skipping a Build #

If you don’t want to run a build for a particular commit for any reason, you may instruct Travis CIto skip building this commit via a command in the commit message.

The command should be one of the following forms:

or

where <KEYWORD> is either ci, travis, travis ci, travis-ci, or travisci.For example,

Note that in case multiple commits are pushed together, the skip command is effective only if present in the commit message of the HEAD commit.

Build matrix #

You can also define exclusions to the build matrix:

All build matrixes are currently limited to a maximum of 200 jobs for both private and public repositories. If you are on an open-source plan, please remember that Travis CI provides this service free of charge to the community. So please only specify the matrix you actually need.

Naming Jobs within Matrices #

You can define names for specific jobs within a matrix. We recommend unique job names, butdo not enforce it (though this may change in the future). Jobs defined in the matrix.includesection can be given a job name as follows:

Jobs that are generated by matrix expansion cannot be given name attributes.

Excluding Jobs #

If the jobs you want to exclude from the build matrix share the same matrixparameters, you can specify only those and omit the varying parts.

Suppose you have:

This results in a 3×3×4 build matrix. To exclude all jobs which have rvm value 2.0.0andgemfile value Gemfile, you can write:

Which is equivalent to:

Excluding Jobs with env Value #

When excluding jobs with env values, the value must matchexactly.

For example,

defines a 3×4 matrix, because the env value does not match withany job defined in the matrix.

To exclude all Ruby 1.9.3 jobs with DB=mongodb set, write:

Explicitly Including Jobs #

It is also possible to include entries into the matrix with matrix.include:

This adds a particular job to the build matrix which has already been populated.

This is useful if you want to only test the latest version of a dependency together with the latest version of the runtime.

You can use this method to create a build matrix containing only specific combinations.For example, the following creates a build matrix with 3 jobs, which runs a test suite for each version of Python:

Explicitly included jobs inherit the first value in the array #

The jobs which are explicitly included inherit the first value of the expansionkeys defined.

In this example with a 3-job Python build matrix, each job in matrix.includehas the python value set to '3.8'.You can explicitly set the python version for a specific entry:

Jobs That Are Allowed to Fail #

You can define jobs that are allowed to fail in the build matrix.

Allowed failures are jobs in your build matrix that are allowed to fail withoutcausing the entire build to fail. This lets you add in experimental andpreparatory builds, for example to test against runtime versions orconfigurations that you are not ready to officially support.

Define allowed failures in the build matrix as key/value pairs:

Conditionally Allowing Jobs to Fail #

Allowed failures can include a condition using the key if.

For example, the following would allow the job using rvm: 1.9.3 to failonly on the master branch:

Matching Jobs with allow_failures#

When matching jobs against the definitions given in allow_failures, allattributes specified on an entry in allow_failures must be met exactly, and allthe keys in allow_failures element must exist in the top level of the buildmatrix (i.e., not in matrix.include).

allow_failures Examples #

Consider

Here, no job is allowed to fail because no job has the env valueSECRET_VAR1=SECRET1 SECRET_VAR2=SECRET2.

Next,

Without the top-level env, no job will be allowed to fail.

Fast Finishing #

If some jobs in the build matrix are allowed to fail, the build won’t be marked as finished until they have completed.

To mark the build as finished as soon as possible, add fast_finish: true to the matrix section of your .travis.yml like this:

Now, the build result will be determined as soon as all the required jobs finish, based on these results, while the rest of the allow_failures jobs continue to run.

Installing a Second Programming Language #

If you need to install a second programming language in your current build environment, you can do so in the before_install stage of the build.

For example, you can use the following recipe to install a custom version of Ruby in a Python build:

You can also install a custom PHP version in a Node.js build like this:

Brew Mysql Configuration

It’s also possible to use other language installation methods such as apt-get, pyenv for Python, nvm for Node.js, etc.

Implementing Complex Build Steps #

If you have a complex build environment that is hard to configure in the .travis.yml, consider moving the steps into a separate shell script.The script can be a part of your repository and can easily be called from the .travis.yml.

See Complex Build Commands for more information on how to do this.

Custom Hostnames #

If your build requires setting up custom hostnames, you can specify a single host or alist of them in your .travis.yml. Travis CI will automatically setup thehostnames in /etc/hosts for both IPv4 and IPv6.

What Repository Providers or Version Control Systems Can I Use? #

Build and test your open source and private repositories hosted on GitHub on travis-ci.com. Travis CI can also integrates with Atlassian Bitbucket, GitLab and Assembla (https://www.assembla.com/).

Travis CI currently does not support git repositories hosted on other version control systems such as Mercurial.

Brew Install Mysql_config

What YAML Version Can I Use in .travis.yml#

Travis CI uses the Ruby libYAML library, which means that your .travis.yml must be valid YAML 1.1.

Troubleshooting #

Check out the list of common build problems.