Contributing golang code

Hi, I’m learning golang and I’m migrating my existing website to HUGO.

I’d like to offer my contributions but I need easy tasks.

Please let me know if there is something easy I can code.


1 Like

You could always take a look at the issue tracker on GitHub. There are currently 110 open bugs and feature requests. I know that I’d love to see this request filled.

Ooh. Don’t do that one. I’m actually working on a big refactor to make adding asciidoc work really well. I’m about halfway done with the refactor. Hope to have it committed next week… but it might take until the following week.

1 Like

I’ll offer a few suggestions.

This also makes me think that we should just have a general thread for simple (starter) tasks that people can pickup and discuss.

  1. Tests. We could use help with better test coverage. This would be a good place to start as it would allow you to pick off just a single part. Another user has done just this and contributed signifcantly over time. His repo is at I’m sure @OwenWaller would be happy to advise.

  2. Adding documentation. I know that this isn’t code, but to add to the docs requires reading and understanding the code which is a great place to start.

  3. Fixing a bug. Here’s a few that shouldn’t be too much trouble:

  4. Adding a feature. Again, some easier ones:


Extremely good suggestions and progression.

I’ll let you know what I picked. Thanks for your time.

1 Like


If it was me, I’d say the tests, the tests and tests :).

On a serious point, if we get the tests in and the test coverage upped,
then it means we can:

  • Pick off the bugs and know we’ve fixed them -> i.e. have test that
    proves the bug, then proved it’s fixed - which is always a good thing.
  • Refactor as required within the safety net of the increased test
    coverage -> so we can tell if the refactor breaks something.
  • Likewise of the new features if they touch existing code.

So, if any of you want to help me, I’ll happily take it. I can point you
at my current repo and we can come up with a plan.

Speaking of a plan, @spf13, so we have a CI system in-place yet? If not
any suggestions, I’d normally use Jenkins, but I’m open to alternatives

[@spf13: Agreed, a “Where to start thread” would be a great idea. Re:
the GuessSection test. The office has been manic this week, so I’ve not
had time to fix it yet. I’ll see if I can make a concerted effort this
week! ]


@OwenWaller - As to CI, look at

Could be “motivational” to set up Goveralls/Coveralls as well.

Thanks @OwenWaller, I’m learning golang so I don’t know how productive I can be.

Nonetheless I’d like to help you on this let me know how to proceed please.

@OwenWaller I’m interested in improving tests too. I’d like to learn Hugo internal more and how it should work. I agree with you that tests let us be confident when we change the code

Improvement on testing would be great and its awesome that there’s people that want to contribute in that way.

Its awesome that people want to improve test coverage.

I’d like to mention that if you want to improve test coverage, maybe check with @SPF13 to see what you shouldn’t work on test wise as he is working some changes that sounds like it might affect a number of things.

When working on tests please break it up into bits, don’t try to fix a bunch of stuff at once and contribute a large pull request that affects a bunch of stuff.

Instead, submit smaller pull requests that address a logical unit, whether its tests for a struct, changes to code to fix things exposed by new tests, etc.

Also, for those who are contributing code please make sure you either update tests or add tests for your changes, unless the changes are such that testing isn’t required. When adding tests for bug fixes its helpful to identify, in the comments, what issue led to this test/fix. This helps prevent regression in the future and is being nice to other developers that might have to look into the code.

I too need to make sure that the changes I submit have proper test coverage-where appropriate.

@OwenWaller, @tatsushid, @tommasop, it might be good to move the testing discussion to Owen’s original thread, listed above, or a new one ,to help co-ordinate/discuss improving tests.

edit: oops, I guess I elided the comment referring to @OwenWaller’s testing thread:

So shall we follow up here ?


Ah ha, we have a travis set up already. I must have missed that one. we
need to get it to start running some of the tests I have.

To give you some idea of numbers, I’ve be poking around in the
hugo/helpers directory and this what we currently have:

$ go tool cover -func=c.out StripHTML 94.1% FindAvailablePort 0.0% MakePath 100.0% MakePathToLower 100.0% MakeTitle 100.0% UnicodeSanitize 100.0% ReplaceExtension 100.0% DirExists 83.3% IsDir 100.0% IsEmpty 84.6% Exists 83.3% AbsPathify 66.7% Filename 100.0% FileAndExt 100.0% GuessSection 100.0% PathPrep 0.0% PrettifyPath 100.0% FindCWD 63.6% SafeWriteToDisk 82.4% WriteToDisk 83.3% Highlight 0.0% SanitizeUrl 75.0% Urlize 83.3% MakePermalink 75.0% UrlPrep 81.8% PrettifyUrl 100.0% Uglify 100.0%
total: (statements) 75.0%

pygments is a point of pain, partly because it is an external tool -
which I don’t user or have installed.

As for gocoverall, I’ve not see that, though ironically I could use it
around the office. What’s you experience with this? Can Travis do this
for us we just need to call go test -cover and then spit out the HTML
file, or the function coverage file (as above).



Yeah more help! :slight_smile:
Keep reading the thread…


@OwenWaller As to Coveralls (goveralls is just a client to handle the go integration) is free (for open source projects) - and is made to be integrated with Travis and Github. I have used it on the Java plattform and it is pretty easy to set up (@spf13 would have to do that, if he’s interested).

As to running your tests on travis: Submit a pull request to Hugo. If you’re not ready to be merged yet, just say so in the PR - and @spf13 will hold off on the merge. Then you can just push new commits to the same branch (and maybe push -f and squash and all the git magic …).

[Sorry everyone. The discuss email interface bounced this message last week because I included more than 2 links. The web interface has just done the same thing so what gives?

Anyhow…better late than never and edited remove the links so I can post this…]


Yeah even more help! :slight_smile:

My original testing thread is here - snipped to get this post onto the list…

To give you all some history. I might have some email between Steve and Nate and myself about what we need to do. I can post this over the next few days, so folks have the complete picture.

OK so my approach to this was simple. Basically get the hugo source, build it, then run the tests, then run the go code coverage tool over it. Pick the module one with the lowest test coverage figure and start to poke at it. Easy :slight_smile:

From memory things where floating around 40-70% for most things. The lowest when I started was hugolib/helpers which is now at 75% see earlier in the thread. That will go up a little more once I get around to killing of a bug we know about in the GuessSection function in the path module. I’ve been slacking due to work commitments. :frowning:

But now there are more of us this is what I suggest…

Either pull my current repo and look in the branch is 'extend-hugolib-tests’
Or pull Steve’s current repo - mine was current as on the 0.13 release which was about 6-8 weeks ago. I do need to catchup and merge in Steve’s latest changes.

Then repeat the steps I took - pick the module with the next lowest test coverage, tell everyone, and see what you can do with it. Or work together on a module if you want to pair up on things. Which is not a bad idea :slight_smile:

Right now, I (and Steve jump right in here…) what to up the test coverage. Once that happens when can go back and see how the tests (as well as the code) can be re-factored. I can already see a few areas where I know I have to write a better test. As we all learn how hugo works I expect we’ll start seeing this sort of thing everywhere.

@mohae I pretty much agree with this. Small commits and changes are good. Although my change might look big it’s really just a refactor to split it out into a small set of files rather than one big test file. All of the change is contained under one directory. And yes, I’ll see if I can start a new “Testing” thread.


OK here are the missing links:

First the original “testing” thread is here:

And my repo is here:


Having a branch live its own life with some massive ongoing changes for a long time is never a good idea. Assume others also are making changes to the files you are touching – eventually rebasing can get messy.

If you’re at test coverage 70, but want to reach 90 – create a pull request with the 70 you got and then another for the next 20.

Yes, please. I’m perfectly willing to take on more PRs, but I’d like to have more tests so that I know that what I’m doing makes sense. The sooner this gets made as a PR and merged, the better.