m-chrzan.xyz
aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorMarcin Chrzanowski <marcin.j.chrzanowski@gmail.com>2019-06-29 15:11:15 +0200
committerMarcin Chrzanowski <marcin.j.chrzanowski@gmail.com>2019-06-29 15:11:15 +0200
commit159875273cb8fdec0354c5d63344e6429cee2cbc (patch)
tree9fffead0332f615207052ac2b66795b7b9ffe27b /src
parentd0b48000703e3dcbf01817fc0bcca99820d5ce83 (diff)
Publish Gitlab + Namecheap blogpost
Diffstat (limited to 'src')
-rw-r--r--src/blog/gitlab-namecheap.html73
1 files changed, 73 insertions, 0 deletions
diff --git a/src/blog/gitlab-namecheap.html b/src/blog/gitlab-namecheap.html
new file mode 100644
index 0000000..cd87ef3
--- /dev/null
+++ b/src/blog/gitlab-namecheap.html
@@ -0,0 +1,73 @@
+title: GitLab Pages + Namecheap
+date: June 29, 2019
+---
+<p>
+This website is currently hosted as a GitLab Pages page. In addition to the
+free m-chrzan.gitlab.io domain name that GitLab provides, it's also
+pointed to by m-chrzan.xyz. This was my first time hosting a static
+site and interacting with a domain name registrar/DNS settings, so I wanted to
+write down some thoughts and tips while it's all still fresh in my mind.
+</p>
+
+<h3>Static site generation for GitLab Pages</h3>
+<p>
+Unlike some other static site hosts (like Git<em>Hub</em> Pages), GitLab doesn't
+have you just upload the html/css/js files for your static site and host them
+directly, but gives you the option to maintain a repo that uses some sort of
+static site generator (say Jekyll, a popular option). It then has you use the
+gitlab-ci system available for every repo to actually compile the website, and
+if that succeeds, makes your website available.
+</p>
+
+<p>
+You still have the option to host a set of plain html files, and GitLab provides
+<a href='https://gitlab.com/pages/plain-html'>a template</a> for that setup.
+</p>
+
+<p>
+One slight point of confusion I encountered was when I missed that the build
+directory has to be called <code>public</code>. Just looking at different
+<code>.gitlab-ci.yml</code> examples, I thought GitLab would look under whatever
+path was specified with
+<code><pre>
+pages:
+ artifacts:
+ paths:
+ - &lt;path&gt;
+</pre></code>
+Initially my generator was putting build files in a <code>build</code>
+directory. This would result in my CI build succeeding, but the external build
+that GitLab does to actually publish the website would fail, without a useful
+error message. A little embarassing how much time I spent debugging this one...
+</p>
+
+<h3>DNS configuration</h3>
+<p>
+I picked Namecheap as my registrar because they're considered reliable, have
+cheap registration (got this .xyz for $1 for the first year!), and they're not
+GoDaddy. Registration and payment was super simple, would recommend. The DNS
+configuration page can be slow to respond unfortunately.
+</p>
+
+<p>
+I've never played around with configuring DNS records, but GitLab's
+documentation had fairly clear explanations. The biggest gripe I had was that
+the official documentation
+<a href='https://docs.gitlab.com/ee/user/project/pages/getting_started_part_three.html#dns-a-record'>
+ recommends against using a CNAME record
+</a>, while the Pages UI under my repo had a CNAME record (and no A record) made
+available for copying, as if that were the recommended route. I ended up
+creating an A record pointing to 35.185.44.232 as described in the docs.
+</p>
+
+<p>
+I had a few issues that I'm not sure if they were caused by Namecheap or just
+expected DNS propagation delays. It took several hours for the A record to
+appear in DNS queries. Additionally, I missed the part where when creating the
+<a href='https://docs.gitlab.com/ee/user/project/pages/getting_started_part_three.html#dns-txt-record'>
+ TXT record
+</a> that verifies ownership of a domain name, if you're creating it for an A
+record, you should just use your top-level domain. Again, confusingly, the
+Pages UI provides a copyable text field to a dummy subdomain and I had to dig
+through the docs to find the correct approach.
+</p>