Using Gitlab CI/CD and Pages to Render and Host Your Markdown Resumé/CV
Example Resumé
Jump to instructions
The importance of a well formatted and structured resumé cannot be understated and early in my job search journey I realised that it needed a revamp. Thus began the quest for looking for a template and researching guides on how to structure my resumé. If you've been in my position, you would know how many options exist with there being no well-defined standard format (except maybe JSON Resumé). Ultimately, I settled on a hacky solution that rendered great looking resumés with a format which seemed minimal and informative using this great repository which I then decided to extend to my use case of maintaining a dynamic resumé with version control on Gitlab.
The Use Case for Version Control and Gitlab CI/CD:
The resumé is a dynamic and evolving document which I also usually tailor to the company I'm sending it to. Version control allows for keeping track of all the changes and how the resumé has evolved over time. The CI/CD pipeline allows for rendering an up to date resumé from markdown each time a commit is made and publishing it which one can then link to from a personal website.
Instructions:
1. Fork the repo on Gitlab:
The repo contains my Resumé in markdown+YAML format as a sample. It also contains the .gitlab-ci.yaml which instructs Gitlab to create a CI job.
2. Make Changes to the Resume.md file:
The Resume.md contains the a YAML block at the top which governs properties of the PDF followed by the resumé written in Markdown. Edit it according to your needs.
The YAML Meta Block(taken from the original source):
name : the name on the resumé.
keywords : keywords to be added to the PDF file.
left-column : a list of lines you want in the left column, directly under the name on the first page.
right-column : a list of lines you want in the right column, directly under the name on the first page.
fontsize : default 10pt
.
fontenc : default T1
.br>
urlcolor : used in PDF, default blue
.
linkcolor : used in PDF, default magenta
.
numbersections : number sections, default off. Can also be controlled using the pandoc
option -N, --number-sections
.
name-color : the SVG name of the font color used for your name on the resumé. For example DarkSlateGray
. Note that this option also changes the font used for your name to bold and sans serif.
section-color : the SVG name of the font color used for sections. For example Tomato
. Note that this option also changes the section font to bold and sans serif.
Regarding the last two options: if you just want to change the font to sans serif bold you can just use the color black
.
3. Review the .gitlab-ci.yml File:
default:
image:
name: pandoc/latex:latest
entrypoint: ["/bin/sh", "-c"]
before_script:
- tlmgr update --self && tlmgr install enumitem sectsty underscore
- mkdir public
pages:
script:
- pandoc Resume.md -f markdown+yaml_metadata_block --template templates/jb2resume.latex -o public/Resume.pdf
artifacts:
paths:
- public
This file is responsible for the CI build on each commit. The first block sets up the build environment; it pulls the latest Pandoc image containing latex, installs the dependencies required by the latex layout defined in the layouts folder and then creates the public artifacts folder.
The second block then has the build command which converts the Resume.md file into the PDF format.
The name of the second block and the path of the artifacts is important. The pages
name instructs Gitlab that the output files from the output folder public
should be deployed to Gitlab pages.
If you do not wish to deploy the output to Gitlab pages, simply change the name of the pages
block to something arbitrary.
4. Commit the Changes!
Once you commit the changes, a build pipeline shall start automatically. It can be viewed by opening the CI/CD submenu from the sidebar and going to pipelines. The pipelines have jobs associated with them. The pages
block we defined in the .gitlab-ci.yaml was a job. Inspecting the job will show you the code the container is running.
5. Inspect Pages URL and Job Artifacts:
Once the build is complete, go to Settings -> Pages, it shall give you the URL to your Gitlab pages.
Navigating to the public
folder.
Further Notes:
- If you make the repository private, the URL you navigate to would also require you to log into Gitab. Great if you don't want to make your resumé public!
- If you like to have multiple versions of your resumé, simple fork the repo again and have create multiple branches for each type of resumé you want to create. I usually do this if I am applying to a job with a different profile which requires me to edit the synopsis and skills.
- There are multiple permutations of the process, like outputting an index.html file using pandoc or creating another format like docx, using a different latex layout to render the markdown resumé, etc. Feel free to adapt it to your needs!
Credits:
- John Bokma for the original repo.