Code coverage is a measure of how much of your code is being tested. It's a controversial metric, but I'll try to provide a balanced take... granted I'm not without my own biases.
code_coverage = (lines_covered / total_lines) * 100
If you have 1000 lines of code in your project, and you have tests that cover the logic in 500 of those lines, then you have 50% code coverage.
It's quite possible to have 100% code coverage and still have bugs in your code. It's also possible to have 0% code coverage and have a bug-free application. Unit tests help us find bugs, and codify the expected behavior of individual units of code but they don't guarantee that there are no bugs.
My personal take is that it's really hard to say "20% is bad, 80% is good". I think some functions and methods are more important to have unit tests for than others. For example, I don't love the idea of mock unit testing external systems, like databases.
I think that's a better use case for integration tests.
As a junior developer, you should know what code coverage is, and you should be amicable to the code coverage requirements of the company you work for. You'll certainly develop your own opinions (and should politely vocalize them) as you gain trust in your organization. It's important to be a team player and to be open minded to your team's processes, especially when you're new.
We won't fail our CI if there aren't enough unit tests, but we should at least print the coverage out to the console. Add the -cover flag to the go test command in your CI workflow, then commit and push your changes.
You should be able to inspect the logs of your latest workflow run in the GitHub UI (the "actions" tab) and see the code coverage report.
Paste the URL of your GitHub repo into the box and run the GitHub checks.