![]() ![]() # GITLAB_USER_NAME User name of the user used to commit the changes to Benjamin Rancourt # GITLAB_USER_EMAIL Email of the user used to commit the changes to the secondary repository. # CI_SERVER_HOST Hostname of the current GitLab instance. # CI_COMMIT_SHA Commit SHA, to use a unique directory name. # The following variables are defined automatically by GitLab CI. # COMMIT_MESSAGE Commit message Automatic update from the weekly schedule # GITLAB_USERNAME Username associated with the personal access token. ![]() # GITLAB_TOKEN Personal access token previously created. Inside Settings -> CI / CD -> Variables, create the following variables: ![]() # repository, to improve the efficiency of the next build process. # This script allows to store the artefacts of a step into the current Enough talk, let's see what this step looks like. You will understand why in the next few minutes.Īs usual, I add a lot of comments to help everyone (including myself) to understand it fully. □️ If you have already read my GitLab CI predefined variables post last month, you will see that I may have use them too much. Today, I am sharing that part with you in the hope of helping you someday. So I decided to commit and push some of the results files created into my Git repository and I improved my GitLab CI pipeline to do that as well. Often, the generated files do not change from a build to another, so why should I recreate them from scratch each time? It may be fine for small websites, but it was no longer a viable option for me. □️īut, as I keep adding content every week, my website has started to take longer and longer to build. One of the heavy steps of my build process is downloading external images and making them responsive for my blog. As my website is a Jamstack project, I completely own its build process (using Eleventy as my generator and Ghost CMS as my backend). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |