All right.
Let's get to it.
We're going to build up our first workflow.
It's going to make sure that we build an image for the service, push the Docker hub.
All that stuff back over on my GitHub repo.
I'm gonna find the actions tab.
And I'm going to make a new workflow.
Once here, I can either click on set up these simple workflow or I can take any other again.
It doesn't matter because we're going to delete everything and build it back up from scratch.
You can click on any of the setup workflow buttons to this window.
We're gonna delete all the code inside there and we'll also rename the file itself.
So we're going to use nomenclature here of the ploy and then the name of the service.
The first service that we're going to try to work on deployment for is the OK service.
Of course, you're going to call this new file deploy dash off dot Yamal.
That inside of here, we're going to put together our config.
That's going to dictate when we run this workflow and exactly what it's going to do.
I to first put in the name property, which will be deploy dash off.
Well, then put an on to dictate when this thing should be executed.
So we want to run this thing and this is going to be a little bit not quite makes sense, but we're
going to run this whenever there is a push.
On a branch.
Of Dash Master.
And we're also going to setup a filter here to say that we only want to run this when something inside
of the author directory changes go under.
Push on the same level of indentation as branches begin to put in parts.
And then a dash and off flash star star like so.
You might be curious, why are we putting pushier?
Well, whenever we close or merge a pull request, that actually counts as a push directly to the master
branch.
So this little check right here is going to run this workflow whenever we merge a pull request into
the master branch.
It's also only going to run if it contains a change to something inside of that off directory.
All right, so after that.
We can go back to the top level of indentation if this editor will cooperate with me.
There we go.
We'll enter in jobs.
We're going to provide a job I.D..
So this is just the name of the job.
Look in use build.
I'm not super picky on this build.
Technically, on our test workflow was not most ideal.
We probably should call it test, but it's not a big difference.
We're going to enter in here.
Let me zoom in just a little bit further to make sure this is super legible.
We're going to enter in runs on the wound to latest.
And then we'll define a series of steps.
The first step we want to run here is check out all of our code inside of our repo.
Before that, we're going to say uses.
Actions slash checkout at BE2.
After that, I'm going to put in another dash and we're going to run a command right here.
The command we're going to run is essentially going to go through this process.
We're going to build out our image and then push it off to Docker Hub.
Whenever we make use of this Lubutu latest operating system, as can the base, really, it is again
a container.
So it's technically an image as opposed to anything else.
It comes with docker or preinstalled.
You can make use of all the docker commands.
We are already familiar with the for example.
We will do a change in 2D auth directory and do a docker build dashty your docker I.D. slash off dot.
And technically, we don't have to change into the off directory.
We actually can run the docker, build command and then say, oh yeah, just go into the author folder.
So instead of DOT right there, we can put it off.
But personally, I'd kind of like just changing into the folder.
It just leaves the docker build command.
Very easy and simple to read.
After we build the image, we're then going to take the image and push it off to Docker Hub.
Remember to push an image to Docker Hub.
We must be logged in to the doctor, see a lie.
The doctor see a lie.
Must know who you are, what your doctor account is.
So before we can push it off to Docker Hub, we have to log in to the Doctor Seelye.
I remember this entire script right here is not being executed on your machine is being ran inside of
some container managed by GetUp.
So we have to somehow tell Docker to log in using it, your username and password.
Of course, we are not going to enter your Dacher username and password directly into the script.
Instead, we're going to add your username and password as a secret into your GitHub repository itself.
Once we add it in as an encrypted secret to your repository, we can then reference that in a secure
fashion inside of the script.
So let me show you how we're going to do that.
At the top of the screen, on the right hand side, I'm going to find settings for this individual repository.
I can open that inside a new tab.
Then once you're on the left hand side, I'm going to scroll down and find secrets.
Well, then add a new secret.
And this is where we are going to individually add in the password and username for your Docker hub
account.
Now, once you add it in here, no one else is going to be able to easily see this information.
So it is absolutely OK.
And this is one hundred percent is where we would want to enter in some protected information like a
password.
So we're going to enter in a name of Docker underscore username.
And we'll put our username right here in.
As the value, so for me, my doctor username is Stephen Grider.
I'm going to add that as a secret.
And then going to add in a second secret or my password, the doctor underscore password.
Now, just so you do not see my password.
I'm not going to show or not going to enter in my password right now, but you can believe that after
this video is over.
I am going to enter my password here and click on Add Secret.
After that, we will have access to our doctor username and password inside of our script.
But here's the script we're just working on.
So how do we use those secrets to actually log into Docker?
Well, let me show you exactly how we're going to enter in a new dash statement here.
We're going entering run.
We're going to say Docker, log in, dash you dollar sign, Docker underscore username.
And DSP dollar sign, Dacher underscore password.
Now we are referencing Dockery's name and password as environment variables when we add in a secret
to a repository, as we did just a moment ago.
Those do not automatically get added into the script as enviroment variables.
Instead, we have to tell GitHub that we want those two secrets to be added as specifically environment
variable called Docker's name and Docker password.
So to do so on the next line down without adding in an additional dash.
So notice how there's no dash here.
We can enter an EMV.
And I'm going to say that I want to have an environment variable inside of my script called Docker Username.
And I want that to come from.
Dollar sign, really brace, curly brace.
Secrets.
Dot.
Dr..
Username closing curly braces.
And then I'm going to repeat the same thing for Dr Password.
And dollar sign curly braces.
Secrets that doctor password.
Now, this kind of stuff right here is where I've found that people in courses a billion times over.
Always tend to make typos.
So I beg you, please double check your spelling.
Double check the number of curly braces.
Make sure you've got all capitals here except for on secrets, of course.
This double check, this section, because I can guarantee you this is going to be a location where
many people make a very subtle, small typo.
So after you run the step, we should now be authenticated with Dr.
And we can now push the image that we had just created in the last step.
So we can then add in another.
Dashed in here and we can run the command docker push and then my case will be Stephen Grider slash
off.
All right.
So that should take us all the way through to this step right here.
And I think that this would be a really good place to pause and then try to test all this stuff out
the next video, just to make sure that we are able to build a new image and push it off.
So let's take a pause right here and continue in just a moment.