In our previous post on Deploying Your Hugo Site Using Netlify, we set up Netlify to automatically deploy our site every time we pushed a commit to our GitHub repository. As well, we set up a custom domain for our site.
In this post, we will look at the preview deploy feature of Netlify to build and deploy to a preview/staging site when we create or update a pull request.
When you create a new Netlify site, a preview site is set up out of the box to build every time you create or update a pull request. The build configuration will match the configuration of your production site. It is fantastic that Netlify set this up for us. However, to take full advantage of having a preview site, it would be helpful to include future and draft posts to make sure they look right before publishing them to production. It would also be nice to be able to test new versions of Hugo in a preview environment before updating production.
In our previous post on Creating a Blog Using Hugo, we installed Hugo, created a new site, added a theme, and created our first post.
In this post, we will be deploying the site that we created using a free account at Netlify. The site will be re-built and re-deployed whenever we push a new commit to our site’s Git repository. We will also look at how to set up our site using our own domain and create an SSL certificate.
Are you ready to capturing and sharing your knowledge with others by creating a blog? Then this series on Hugo is what you are looking for. Even if you have never used or heard of Hugo you will be able to create your blog and deploy it. In this series of post on Hugo, we are going to build a full blog based on this website. By the end of the series, you will be able to add posts, have a page to view past post by date/category/tag, have an rss feed so people can subscribe to your blog, be able to add pages such as contact, search and about plus we will dig into several useful Hugo features to take some of the work out of creating your blog and post.
I was trying to add a code block to a post to show how to generate an html figure using the Hugo built-in figure shortcode and it instead of showing the markdown of the figure, it kept rendering the actual figure.
I could have just took a screenshot of the code but the whole point of having the code block is to make it easier for you the reader to easily copy and paste the code. The key to making this work is knowing how to escape the figure shortcode within the code block so that Hugo renders it as a code block and not a figure.
Recently, I had to create a Github account for work in addition to the one that I have for my personal repos. Not a big deal having two accounts but figuring out how to switch the account to use depending on the repository was difficult to figure out.
Luckily, the solution is really straight forward to implement. methods
Starting with Cypress 6.0, the cy.route and cy.server commands were deprecated and replaced with cy.intercept.
Cypress is currently at version 9.4
Unlike cy.route(), cy.intercept():
As your number of Cypress tests grows you are bound to end up with some duplicate code that would be better to put into a reusable function.
Luckily, Cypress allows us to create our own custom
cy commands that are available to all of our tests.
In our previous post, we talked about how TeamCity automatically combines multiple dotCover outputs into a single code coverage report but what if we wanted to keep thoose reports seperate?
You might be thinking why would you want to do this? Don’t you want to see the overall test coverage?
The overall coverage is nice but when you have both unit tests and integration tests, or multiple test projects serving different purposes, there is a high potential that you are reporting lines of code being covered that were only called but not actually tested.
In this post, we are going to look at how in TeamCity you can run multiple test builds to generate both individual reports and still have a combined report.
In TeamCity, what if you need to combine the code coverage results say from unit test and integration test projectsthst run as seperate build steps?
Luckily, TeamCity does this work for you but it is not obvious that it will do it for.
To get TeamCity to combine the multiple the code coverage results into a single code coverage result, you just need to add the echo command to import the data into the build like we did in our previous post
In this post, we are going to add our code coverage to our TeamCity builds to run our unit tests with code coverage as part of the automated builds, show us the code coverage metrics summary after the build, be able to view the code coverage report right in TeamCity and add failure metrics for if code coverage percent drops.