Laravel deployment with GitHub Actions

hey youtube in this video we're going to take a look at deploying a layer of application towards multiple servers without any downtime using github actions before we dive in my name is filo and you're actually watching my very first youtube video about which i'm both excited and also a little bit nervous i'm a self-taught developer and my journey started 20 years ago with frontpage anyone who remembers that kinda makes me feel old anyways i've decided to dedicate 2021 towards sharing what i've learned over the years learning how to program getting started as a freelancer but also co-founding a startup and the roller coaster that awaits you when you get your first investment but let's leave that for future videos and get started with deploying our application towards multiple servers without any downtime using data [Music] action let's start with a quick introduction to github actions github actions allow you to trigger a workflow when specific github events occur for example you can run a test suite when a pull request is made or in our case create a build of our product and upload it to multiple servers when the commit is pushed to our master branch our first step is to create a new repository on github so i'm going to create a new repository called hello world i'm going to make it private and i'm going to create it okay so in this example i'm going to use a plain laravel installation but you can use any project that you want whether it's a wordpress website a static website it doesn't really matter you can just follow along and adjust accordingly so i'm going to switch over to my terminal and i'm going to use the laravel installer to install a plain version of the framework next i'm going to add our data repository to our local environment so we can easily push to get up when we make changes now let's add the code that we have so far and let's push it up to get up okay so we have our repository set up now we can move over to creating our workflow let's open up our editor and let's create our first workflow file github actions uses a yaml syntax to define the events jobs and steps these yaml files are stored in our repository in a directory called github slash workflows so let's create that now create a new file type dot github slash workflows you can name your workflow file anything you want in this case i'm going to name it deploy application.yml like i mentioned github uses a yaml syntax so we're going to first define a name i'm going to call our workflow deploy application next we want to define the trigger that's going to trigger this workflow so i'm going to say on push and i only want this event to trigger when a push has been made on the master branch next we're going to start with our first job we basically want to prepare our application so that it's ready to be run on the production environment in this case we're using laravel so we want to make sure that we compile our css our javascript and install our php composer dependencies let's start off by giving an identifier to a job let's call it create deployment artifacts next we're going to provide it with a name that's going to be displayed in the github interface let's call it create deployment artifacts next we're going to define our runner our runner is basically a server that has the github actions runner application installed in this case we're going to make use of a runner that is hosted by github and we're going to choose ubuntu latest now we can continue by defining the steps that we want to execute on our runner in this case on the ubuntu latest environment so we're going to start off by importing our repository code by default it's a empty os so it's just ubuntu with no source code whatsoever so in our first step we're going to make use of an existing action in this case the checkout action which is provided by github which allows you to check out your source code into your runner with just a single line of code so now that we have our source code we can continue by pulling in our npm dependencies compile our css and javascript so start off by giving it a name and next we're going to use the run parameter to define a command that we want to run inside our runner which is ubuntu latest so be using the pipe character you can enter multiple lines so in this case we want to do npm install and npm run production this will install our npm dependencies and compile our css and javascript let's push the changes that we have so far up to get up and let's see what happens when you switch to get up you'll notice this orange indicator this indicator tells you that a workflow is currently running so when you click actions you will get an overview of all your previous workflows that have been executed and the ones that are currently running and as you can see our workflow is currently in progress click it you will get some more information about the different jobs which exist inside this workflow in this case our create deployment artifacts with the power of video editing i'll make sure that i cut out any waiting time so you don't have to wait for every workflow to be completed our first workflow has just completed let's take a look and see what has happened here you get an overview of all the different steps inside the create deployment artifacts job you can see that it has a setup job which is defined by github and you can see that it's downloading the required actions that we define in our workflow in this case it's calling the checkout action you can see that it checked out our hello world repository next we got our compile css and javascript step and you can see that it downloaded our npm dependencies and it successfully compiled our javascript and css okay next up want to make sure that our runner is configured with the correct version of php in this case we're going to configure it with php version 8 and we're going to make sure that certain hp extensions are enabled which are required by level in this case we're going to make use of a community build action this action is going to help us to configure php inside our runner with just a few lines of code so let's reference the action that we want to use and let's provide it with your required input parameters let's define our version of php which is 8.0 and now let's define the extensions which we want to include in this case level requires mb string c type file info openssl video emath json tokenizer and xml let's commit these changes and push them up to get up and see if it works switch back to our actions and as you can see a new workflow has been queued let's forward to the output of our php configuration you can see that it found version php8 it set up composer which we need to install our dependencies and then enable the extensions which we defined in our yaml file so now that we have php configured and composer installed we can install our composer dependencies so let's create a new step and let's call it install composer dependencies next we want to run a command inside our runner we can do composer install no dev because we don't want any depth dependencies on production we add the no interaction flag because it's an automated process and we want to state that we prefer the distribution source okay so let's quickly commit these changes and take a look again going to speed up this a little bit in post production and there you can see our php composer dependencies have been installed successfully okay great our build is complete so now we can prepare it to be shipped to our remote server in this case i want to create an archive of the entire application so we just have one file to work with okay let's name our next step let's call it create deployment artifact followed by the command that we want to run inside a runner in this case we're going to create a archive we're going to use the tar command with the c flag to tell it to create a new archive we're going to use the z flag to tell that we want to use g zero compression and we're going to use the f flag to define that we want to have the output in a file let's name the file app.gz now what will happen it will create an archive from all the files in our current directory and as you remember we've installed npm dependencies that we actually only needed to create this build so we want to make sure that these files are not included in our archive we can achieve this by using a exclude flag and we can define a pattern that we want to use to exclude for example the git directory or in this case the node modules directory let's push these changes up to github and verify that the results are as we expect the job has been completed you can see that the command has successfully executed since we're pushing this file up to our remote server the file name app.gz is a little bit unclear we're not sure which release is actually inside so i want to make sure that we can identify each release by naming the file of our archive and make sure that it's equal to the commit hash we can do this by using a get up action syntax which is available in these specific yemo files so start off by renaming our app and use a an environment variable that will be equal to our commit hash now this environment variable doesn't exist yet so we need to make sure that the runner knows what the github commit hash is we can achieve this by using the environment flag so we're going to tell it that the environment variable github sha is equal to the commit hash if you want to know more about the available properties that you can reference be sure to check out the documentation on github.com so let's reference the commit hash and that's it we can now continue with our next step which is uploading our deployment artifact okay let's define our next step and we'll start off again by providing it with a name let's call it store artifact for distribution next we're going to use a getup action again just like the checkout action github also has a specific action which allows you to upload build artifacts we're going to use the uses key to reference actions slash upload this action requires a couple of parameters so we're going to use with to define these parameters we're going to start off by a name this is going to be the name of our artifact that we can use for later reference for example in a future step we want to download these artifacts and we need to reference the name that we define right here so let's call it app dash build next we need to tell the upload artifact action to tell where we can find our file that we want to upload so we're going to reference the archive file we've created earlier the commit hash as our file name plus star.gz let's commit our changes to git up and verify that everything works okay so our workflow is running let me quickly fast forward to the end of the job okay there we go as you can see we now have one artifact with the name app built and it's a little over 3.6 megabyte okay so now we can work on uploading our artifact to our servers but at the moment we don't have any information about our service just yet so in this case i want to create a new json file which will contain a list of our servers with the required information like ip address authentication like username and password and a bunch of other configurations so let's start off by creating a new file in the root of our repository called deploymentconfig.json start by giving our server a name and it's just for easy reference so when we take a look at the github ui we can easily spot it followed by the ip address of our server next we got our username let's enter root let's add a password as well i'm going to set it to git up actions for now next we got our port which is 22 for ssh i want to be able to set a hook before and after the deployment on each server so we're going to add a before hook option where we can enter any command that we want to run before our release is activated for example we can run a database migration or run a database backup you name it when a release is complete we might want to send out a select notification so let's create an after hook configuration option as well next we want to set up a server path which is where our website will be located so in this case i'm using engine x i'm going to point the directory to far slash www html i don't have a server set up just yet so let's head over to digitalocean to quickly configure a server if you already have a server up running that's totally fine you can just skip ahead to the next part so let's start by creating a new server i'm going to use a marketplace image which has linux mysql and php pre-installed select the type of server we want to use i'm going to choose amsterdam for my region and i'm going to use password authentication for this example but i highly recommend that you use ssh keys in production okay so the password that i've entered earlier in the server configuration does not meet the password requirements from the digital ocean so let's make this one a bit more complicated let's make sure that we also update our password in our configuration file okay so let's leave the host name as it is and that's it let's create our server okay let's copy the ip address and let's see if we can ssh into our server there we go that seems to work now let's quickly verify that our server can be reached and that our web server is up and running there we go that seems to be working as well by the end of this video we will have achieved the following directory structure now i want to point out the current and releases directories the releases directory contain the releases that we upload these are our unarchived artifacts when the archiving is done we swap out the current directory and point it to the new release so the current directory doesn't really exist it's more like a shortcut into our release directory so we need to make sure that our engine x configuration is pointed to this current directory so let's ssh into our server and make a change to the engine x server configuration let's change the root directory of our web server and open the current directory now in our case we're deploying a laravel application which comes with a specific public directory and we need to point our web server to that directory so let's append public as well let's save our changes and restart nginx and if you reload the browser then you can see that the changes have been made to the nginx configuration but that it currently cannot find that directory let's update our configuration file with the ip address of our server in this example we just have one server that we're going to work with but you can add as many as you like although github does has a limit when it comes to the deployment matrix in which we're going to talk next and this has a specific limit of 265. so if you exceed that limit then you'll probably have to look at a different solution okay so before we can continue we need to export our configuration file that contains our servers and make it available inside our workflow in order to do this we need to add an additional step let's create a new step and let's name it export deployment matrix and basically what we're going to do is use the runner to load the contents of the deployment configuration file echo it out to the command line interface and use a special syntax so github understands that we want to make this information available inside our workflow since you want to reference the output of this specific job later on we want to provide it with an id so let's name it export deployment matrix next we'll define our command let's create a json variable and assign it to the contents of our deployment config.json file so this doesn't work really well with multi-line json files so i found a piece of code which basically escapes the multi-line json file that we have and make sure that it works so now we're going to echo out our json but we're going to prepend it with a specific name which allows github to read it so we can do set output we're gonna provide it with a name we're gonna call it deployment matrix next we're gonna provide it with the value in this case our json string okay now we need to tell github that we want to store this information so we can use it for later reference so scroll back to the top and add a new input parameter called outputs to the create deployment artifact step provided with a key that we can use for later reference in this case we're going to call it deployment matrix next we'll use github specific context information that we've used earlier to get the git comment hash and now we're going to reference steps followed by the id of our step in this case export deployment matrix output followed by the name that we've provided in the echo statement which is deployment matrix okay we're all good to go to move on to our next job in this case preparing the release on our server so let's name it prepare release on server now we're gonna define that this runs on the latest version of ubuntu as well next we're gonna use the needs parameter to make sure that our previous step has been completed otherwise they will run asynchronous and now we're going to work on our matrix so we use the strategy input parameter use the matrix keyword to build a matrix configuration you can basically see this as a for each loop the steps that we define in this job are going to be repeated on the objects with inside the matrix in this case this is going to be our server configuration so we're going to load the json which we exported in our previous step into the repair release on server step okay so the matrix is going to loop through our json file and we want to provide a name that we can use to reference the information in our json file in this case we got a list of servers so let's use the keyword server the matrix expects a array to be provided at the moment we have a json string so we're going to use the function called from.json provided with the output of our previous step we can do this by referencing of the chain so we're going to say needs dot create deployment artifacts dot outputs dot deployment matrix which matches up with the output variable that we defined earlier now that we have our matrix setup we can continue with setting up the steps for this specific job so we want to start out by downloading the artifact from our previous step so again we're going to use a github specific action which is called action slash download artifact so this action only requires one input parameter which is the name of our artifact so let's enter app dash build let's commit the changes to get up and take a look okay so our export deployment matrix step has failed let's take a look at our workflow file to see what's wrong ah it looks that i forgot a quote let's try that again and there you go this time it has completed successfully and on the left hand side you can actually see that it has successfully read our matrix as you can see that it's saying prepare release on servers and you can actually see that it's referencing server one with the ip address again this includes the credentials as well so in production make sure that you use repository secrets and ssh keys okay so we got our artifact downloaded next we can upload it to our servers again we're going to make use of a community build action which allows us to upload our zip file to our servers first let's create our next step let's name it upload followed by the users parameter to provide the action that we want to use in this case apple boy scp action by the way if you want you can copy and paste the name of your action and just head over to github.com the name of your action and you actually see the source code of the action which is being run behind the scenes so here you can see these actions allow for copying files and artifacts via ssh and on this page you can see the usage input variables and code examples on how to specifically use this action okay let's head back to phpstorm and provide the necessary input parameters i'm going to start off with the host which is going to be equal to the server ip we've got the server ip in our deployment config so we only need to reference it here we can use the server object inside our matrix to be defined above so in this case matrix.server.ip which will reference the ip address inside our deployment config let's repeat this process for the username password or next we're going to define the source which is going to be the file that we want to upload so this is going to be equal to the commit hash so again we reference github dot sha we append the file extension which is dot tar.gz next we're gonna define the target this is going to be equal to the directory where we want to upload the file on a remote server so in this case matrix.server.path to reference the server path that we define in our deployment configuration now let's make sure that our artifacts are grouped nicely together inside a single directory so let's append the server path with a new directory name called artifacts this will be equal to far slash www.html artifacts let's commit our changes and push them together let's verify that our action is working and that our artifact is uploaded to our server let's fast forward to the end of this workflow there we go it successfully executed the transfer to our server let's ssh into our server and verify that the file's there so i'm going to check inside our var slash www html directory to see if our file's there it looks like something went wrong because we only got our index.html so let's take a look and it seems that i've got a w inside the server configuration where we define our server path let's commit the changes and try this again the workflow has successfully completed the upload has been completed and it looks like that it created the folder in the correct place so let's check our server and there we go our artifacts directory is there and it does contain our archive with our current release okay so we got our file on our server now we need to extract it so that we have a release to actually work with so let's create a new step let's name it extract archive and create directories so in order to extract our archive we need to ssh into our remote server we're going to use a another action by the same author called appleboy slash ssh action which will allow us to execute remote commands on our server i'm going to copy and paste the hostname username password import since those are exactly the same as in our previous step next we'll use the script input parameter to define the commands that we want to run on a remote server let's kick off by creating a new directory that will hold our current release let's use the make their command to create the directory if it doesn't exist yet let's reference our server path followed by the releases directory followed by the commit hash now this github underscore sha environment variable doesn't exist yet so let's make sure that we pass it inside our input parameters for this specific action so let's set the n flag and let's define github underscore sha to be equal to the commit hash of this release environment variable will now be available inside our runner we want to make sure that it's also available for us inside our remote server we can do this by providing a environment input variable for our action so now this environment firewall should be available on a remote server let's extract the contents of our archive into the release directory we just created we can use the tar command to extract our archive so let's do tar x z f followed by the path to our archive file which is equal to our server path followed by the artifacts directory followed by the mid hedge of our current release and of course the file extension which is dottar.gc next we'll add the c flag to make sure that the tar command understands that we want to extract contents into the releases directory which again is our server path followed by slash releases slash our release commit hash time to commit our changes again and push them up to get up to verify that everything works let's fast forward again to the output of our workflow okay it seems that our job has filled so let's take a look what's going on cannot find our archive and it seems that the name is incorrect because those brackets shouldn't be in there so let's take a look at our workflow and there you go i made a mistake right there the dollar sign should be before the bracket so let's change it let's push the changes to get up and let's try again this time the job has successfully completed so let's ssh into a remote server check the release directory and make sure that our files are there and there we go our laravel application has been extracted into the release directory let's head back to phpstorm and continue with our workflow we're going to make some specific changes for our larva application if you don't use level you can still follow along we're going to work on something which allows us to share storage between different releases if you're unfamiliar with laravel basically it ships with a storage directory inside our repository this directory is somewhat empty but on our production release we might actually have files in there and of course we don't want to overwrite our files on our server so let's make sure that the storage directory is removed from our release so we can link it up to our shared storage directory so we use the rm command to remove this directory which is located in our server path followed by our releases directory our release commit hash followed by the name of the directory which is storage next we'll replicate the storage directory structure but outside of our release and again using the make their command to make a storage directory inside the storage directory we're going to create a couple of new folders which are required for the laravel framework in order to function in this case app public framework and logs our framework directory requires a couple of extra directories let's make sure these directories exist as well in this case cache sessions testing and views finally we need to make sure that the storage directory and all sub-directories are writable so let's make sure that we provide the path to our storage directory and continue with our next show so in our next step we are going to run our before hooks which allows to execute any commands before our release is activated let's identify our next job by calling it run before hooks and of course let's give it a name as well if you want to make your steps easier to read you can actually reference your matrix object within the name as well so for example we could do matrix server.name to get the name of the server and add beforehook so in the github ui we'll get server one beforehand which makes it easier to identify on which server the actual job is running we're gonna repeat a couple of things of course again we're gonna make sure that it's running on the latest version of ubuntu we're gonna define our needs parameter to tell it that we want to have our create deployment artifacts and our prepare release on server jobs to be completed we're going to reference our matrix again and let's just copy and paste it from our previous step let's name our step run before hooks let's save ourselves some time by copying the step from our previous job to execute a command on a remote server next we'll add the script tag again followed by the before hook from our server configuration by referencing our matrix objects so let's do matrix.server.for hooks inside our server configuration we can now define our beforehooks these beforeholds will be executed before we activate release so you might like go into a certain directory and execute a clone it would be pretty nice if we don't have to do things like far slash www etc but we can reference a environment variable which makes it a bit easier for us for example we could do c d release path in order to get in our current release directory this won't work just yet we need to make sure that the environment variable actually exists so let's define our environment variable which we called release underscore path we'll reference the server path followed by the releases directory followed by the directory name which is equal to our release commit hash okay next we want to set an environment variable that we can use to reference the path to our active release so let's name this environment variable active underscore release underscore buff followed again by the server path followed by the current directory next we also have a storage path which is the path to our storage directory and the base path which is nothing else than our server path now let's make sure that these environment variables are actually available on a remote server by again going to the input variables for our ssh action and defining the ends input variable followed by the environment variables that we want to make available in this case our release hash our release path our active release path our storage path and our base path now we of course want to make sure that this actually works so let's head over to our deployment configuration and echo out the github commit hash time to push our change up to get up and take a look it seems something went wrong the workflow is not valid job run beforehand depends on unknown job prepare release on server so let's take a look and it seems i've got an s right there let's try again this time our workflow has successfully completed let's verify that our commands are successfully executed that looks good let's verify on our server and our storage directory is there and you can see by the green highlight that the write permission is set correctly next we got our before hook let's open it up and there you can see we echoed out the github commit hash and on line 30 you can see that it is equal to 884 etc so that is working as well our environment variable is available on a remote server now it's time to work on the most exciting step activating our release let's just copy paste to run before hook step since the active release app is going to be a couple of ssh commands as well let's rename it to activate release of course make sure that our run before hooks has actually completed before we run this job change name to activate release as well let's change the step name okay i think i spot a mistake that i made in the previous job and there should actually be a single dollar sign instead of two so let's make sure that we update this across the file i think we got them all let's replace it with a single dollar sign and two brackets okay so now we want to make sure that our current directory is pointing to our new release we can do this by sim linking we're gonna simulate the current directory to the directory that holds the current release we'll use the ln command to set up a symbolic link the s-flag means it's a symbolic link the n flag tells it that it's just treated as a normal file or directory and dash f tells it to force or overwrite a link if it already exists this is then followed by the path to our new release and we want to make sure that it's linked up to our slash current directory or as we referenced before as the environment variable active and the score release and square path in case you are using engine x with php fpm you need to make sure that php is actually reloaded otherwise it will not pick up the changes when we swap out a symbolic link so we'll do this by doing surface hpa fpm reload time to verify that everything works so let's push this up to get up and take a look at our job in this case it has successfully executed commands on our server it has set up the link and it has reloaded php8 let's verify this on our remote server and there we go as you can see our current directory is currently simulink to the release that we just deployed let's see the interrupt current directory to verify that our application is of course actually there and there you go if you would head over to our browser you can see that it isn't working just yet this is because we still need to set up a couple of things in order for this level application to run successfully if you're unfamiliar with laravel it ships with a environment configuration file this file basically contains things like the application name the url database settings etc etc this file needs to exist and needs to have a couple of configuration options defined in order for our framework to work let's kick off by creating a environment variable that's called laravel and score n and let's make sure that equals to the level and secret secret again is a keyword that is context specific to this creative action and we can define our secrets within the github ui so head over to your repository go to settings secrets new secret let's enter the same name that we defined in our workflow file which is laravel and screen and i'm just going to copy and paste in a example environment file that ships with laravel and i just changed the app name and the environment to production now during each deployment we want to make sure that our environment file is updated it doesn't exist right now so let's make sure that it does we will use the printf command to echo the contents of our secret into our environment file which is going to be located in our base path of slash.nfc this file needs to be inside our release so we're going to use the link command again but this time we're going to link the environment file from our base path to our release path i could argue why not create this environment file inside the release directory well that will result in a lot of environment files scattered across all our different releases i prefer to have a single file which is a single source of truth this makes it easier to work with since we're here let's link up the storage directory as well we'll use the ln command and reference the storage path followed by the release path which basically means that we now have a storage directory available in a release which is simulink to the storage directory inside our base path let's trigger the workflow and verify the results on our server okay everything has successfully completed let's take a look at our website and unfortunately it seems that it's still not working let's go back to our server and take a look our files are there the end files is there it's correctly linked current directory is there but the environment file is empty let's see our level and is defined i've got to pass the environment variable to our remote server so let's give this another try okay our workflow has successfully completed but it's still not working let's verify that there are environment files there okay that seems to work but it's not yet working okay i quickly paused the video for a second i forgot to update my engine x configuration this server is proficient with php 7.4 which i upgraded to version 8 but i've got to update the engine x configuration that was still referencing to php 7.4 so let's change it reload nginx and try again and yet it's still not working let's dive back into the server and check the error log so larval is complaining about the fact that we provide a envelope cache path so it seems that i forgot to create a additional directory inside our storage framework cache directory which is a data directory so let's quickly create this right here make sure that it has correct file permissions and refresh and there you go we have successfully deployed our laravel application so we've manually fixed it on our server but of course you want to make sure that it is fixed in our workflow as well so let's head over back to phpstorm scroll up and let's make sure that the data directory is created inside the cache directory let's copy and paste our previous command and let's adjust it accordingly and next up we got our after hook so to make things a bit easier let's just copy and paste our before hook since it's almost the same let's make sure that our activates release job has finished before we triggered the after hook by adding it to our nice array next we'll update the identifier to run after hook we update the name as well and the name of the step and finally let's make sure that we reference the after hooks from our server configuration okay great our after hook is done as well let's continue with a little bit of a cleanup every time this workflow is triggered it will upload our artifacts now if you do this 100 times this will mean you have 100 artifacts and these artifacts take up disk space and you probably don't want to end up with your server crashing in the middle tonight because it has run out of disk space so let's make sure that we clean up the releases and artifacts directory let's copy and paste our run after hook shop and let's make some changes let's change the identifier to cleanup update the name accordingly and the step name as well of course make sure that our after hook has completed before we are running the clean up we don't need the environment variables that we created earlier so let's remove them and replace them with two new environment variables we want one environment variable to reference our releases directory and another environment variable that references our artifacts directory now we need to make sure that these two environment variables are passed to a remote server so update the ends input variable of our ssh action let's cd into our releases directory and list all the releases by time and date next we'll use the till command to offset this list by 5 and return any remaining directories that might exist we'll use remove command to remove any directories that are returned by the tail command now we want to replicate this behavior for our artifacts directory as well so let's copy and paste this line and update the environment variable to reference our artifacts path time to commit this to git up and trigger workflow to verify if this works let's fast forward again to the output of our workflow so our commands have been successfully executed on a remote server so let's verify this by let's verify this by listing our releases and of course our artifacts as well as you can see there are five remaining of each and all the additional files have been removed that's it we've successfully deployed our laravel application to a remote server without any downtime in this video we've used a single server when we deploy our application i've duplicated the server that we've been using three times so we have a total of four and i've updated our server configuration to include these additional servers by default github actions run in parallel which is quite nice as you can see right here it's executing the prepare release job on all our servers simultaneously to see this in action i've also updated our level application to include the server name on the welcome page so if we take a look you can see that the documentation title has uploaded to server 1 server 3 server 2 and server 4. i hope you enjoyed this video and if you'd like to see more of these be sure to support me by clicking the like button and subscribing to my channel i truly appreciate all the support oh by the way if you have any questions drop your comment below and i'll get back to you

Channel: Philo Hermans

Views: 4,372

Keywords: laravel, github, github actions, atomic deployment, php, deployment, devops, zero downtime deployment, tutorial, how to, programming

Id: 2zduPKmszmI

Length: 49min 45sec (2985 seconds)

Published: Mon Jan 25 2021

Reddit Comments

[u/c17r]

I don't think advocating putting account usernames & passwords into a deployment-config.json is a smart recommendation, even if the repo is private.

[u/c17r]

It's recommended to use npm ci in an automated pipeline instead of npm install https://docs.npmjs.com/cli/v6/commands/npm-ci

[u/PhiloNL]

You can also find a written version of my video here. I'm looking forward to hearing what you guys think!

[u/lonnyk]

nice stuff - I watched the first half of the video, but didn't understand why you do two jobs in the action when they have to run serially. Did you cover this anywhere? What's the point of the second job? Why not just more steps in the first job?