In this lecture, we'll have a look on how you can use a psi to build our project, though the exact
step that we did on our own machine will try now to replicate using telepathy pipelines.
I have now opened a project in an idea, and I'm using Visual Studio code, which is actually free to
download and install, but if you want.
You can still use the get kept at CNN.com interface to edit files if that's easier for you, so it really
doesn't make a difference.
So let's try to create a pipeline that will build of a project.
And for that, you'll see here that we do not have a pipeline definition file, so we don't have a file
that defines the pipeline.
So let's go ahead and create one.
And the first step would be to build a website, so let's define a step, build the website.
And a script, no.
And we have a couple of steps we need to do now.
First of all, this is a JavaScript project using npm and this package Jason File defines a set of dependencies
which should be installed.
Otherwise the project will not work.
So these dependencies are by default installed in this folder called node modules.
And this isn't something that is being checked in with the repository wouldn't make sense.
It would be a lot of files.
So every time somebody needs to check out this repository and try it out to see how it works would first
need to install all the dependencies needed.
And this is a step GitLab needs to do as well, because otherwise, without its dependencies, it will
not be able to build the project.
And in order to install dependencies only need to do is use npm install.
Now, the second tool that we are using is Gatsby. for generating this website, for building, for
taking care of this build tools, everything that's happening there.
And of course, by default, Gatsby isn't installed as well, so we'll need to install Gatsby.
And I'll finally step that we actually wanted to run, is Gatsby built?
Now, let's go ahead and commit these changes and see how our pipeline looks like.
And now the pipeline is running.
And let's take a look on how the output looks like.
Unfortunately, we do have a problem with our pipeline and we have an error, and it is clear that problem,
the command that is generating this error is npm install.
The error is pretty clear command not found.
So what does that mean?
Well, by default, we are using a Docker image that is by default integrated with Typekit lapses.
So what the runner is using is by default, this image ruby in version 2.5.
And apparently, this image doesn't have node and npm installed.
And because you remember locally, we had to install node and r.p.m. and in order to use npm install
in everything, we sort of would need to do the same on GitLab.
And the way we work with this is that we use Docker images.
So the idea is not to take this image and manually start to install node every time, because that would
be a possibility as well just to type in a comment in order to install node.
But ideally, we'll take a Docker image that already has node installed.
So a simple search on the internet for Docker image node or whatever else you're looking for will most
likely lead you to website like this.
Now I'm currently at Docker Hub, and this is like a repository with all the images that are being built.
And anybody can publish these images.
They are like official images from almost any software provider out there that's generating these images
so that everybody can use it so that you do not have to worry about this additional steps.
The name of this image is quite simple is node.
And if we don't specify a version, it will always check out the latest version, but there's the possibility
of specifying a specific version if that's needed.
So let's go ahead and change our pipeline a bit.
So in order to specify an image, all you have to do is go to your job and say image.
And I'm going to write your note.
Let's save it and see how this pipeline looks like.
It will see now that when the pipeline is starting, instead of pulling the ruby image, it's pulling
the Docker image node.
And this is exactly the image that we have specified here.
And probably noticed by now that GitLab CII is not so fast, especially if you previously have worked
with continuous integration server like Jenkins.
And the difference is how GitHub is working and especially the usage of Docker, and that everything
that is being generated here is thrown away after this has been executed just after the job is done.
All this information is no longer available.
And if you have any experience with Jenkins and if you don't have don'tworry in Jenkins, you have somethingI
workspaces and every time a job is running, it has its workspace and don't have to download all these
dependencies over and over again.
And later in the course will look on how we can make our jobs a bit faster.
But generally, you don't have to worry now in the beginning, why your jobs take a bit to execute.
Now our job was successful and then the static website has been generated.
Unfortunately, as I have previously explained, once this job is done, you have nothing to see.
So the execution is completed, but the work said that we have built isn't available.
So what we need to do next in order to use the artifact that has been built.
So the artifact in this case is the website that we are building is to specify where is the artifact
so that we can save and inspect it?
For that, we're going to use artifacts.
And the path that we are interested in is inside the folder public.
So I'm going to simply say public, but you can also specify it like dot slash and then you're referring
to the current rectory where inside.
This is a bit more specific than just saying public.
Now, the job execution is done, you'll see that the artifacts have been generated and now uploaded,
and here on the right side, you will be able to either download them to inspect them on your computer
or for specific files you can view indirectly in the browser.
So I'm going to click here and browse.
And you will see the public folder that we have selected.
And if I go inside it, you will see all the files and folders that are related to the website and you
will not see anything like node modules or something of that.
It's only the static website that we are interested in.
This is the production build that we want to deploy.
So the rest of the repository, what we have inside is something that we are not interested in deploying,
and it will be a lot of files that will be totally needless because they are like private files.
These are public files that have been generated.
So this is how we have migrated this built job from our own computer to get lspci and have managed to
build this artifact.
Just to recap in order to use 21:00 A. We first have to use a Docker image that already provides node
that has node already installed.
And after that, the steps that are needed are pretty simple and are inside the documentation.
We have to install all the dependencies.
And then we're using Gatsby. Seelye to generate the build that.
Now this gets Gatsby. website has and the artifact will be generated in the public folder and we are
saving it instructing GitLab.
This is the artifact.
We want to save it for later stages, so make sure to keep it and not throw it away after this job has
finished.