(write bout my experience with them in other projects.)
CI/CD pipelines are one of those concepts you'll usually encounter when working on projects to be deployed in production. In my experience, they're usually the source of truth to verify whether the changes performed in the codebase didn't break anything else. This is specially beneficial in projects that build in different platforms, architectures or operating systems. I've been somewhat familiar with them ever since my first Co-op at Kinaxis(If I recall correctly — the system we had in place wasn't as advanced as the one it is possible for us to handle with Github Actions, given that we had to manually trigger the runs, which was very annoying).
I could mention a lot of reasons why it is necessary to have CI/CD pipelines, but perhaps you might find them important in two cases:
we may want to enforce a certain coding style throughout the code base. So that all of our files have the same formatting style.
In Projects that I've contributed to, like LLVM, which is meant to target multiple hardware and operating systems, whether it is a system running X64 or ARM64 and whether its OS is Linux, Windows or macOS, you want to verify that all of your tests you'll write work just as well between each other.
Now here are my responses to the questions.
- How did you set up your GitHub Actions CI Workflow? What did the YAML for this workflow look like?
I'm not the best at writing these YAML files from scratch. I find the most effective way of setting a CI in your project is mostly through some sort of template. GitHub provides facilities for this when you instantiate a repo. It is widely recommended to research linters, formatters and the respective testing frameworks to integrate them on every "serious" project's CI.
- How did your partner's repo and testing setup differ from yours?
To be honest, I had never written tests in Go; therefore, this was somewhat of a new process for me. What always surprises me about Go is the inherent simplicity that forms the language. Every time I find a project, I find it syntactically familiar. Regarding the tests, it quite surprised me the way the comments were laid out — as if it was related to some mathematical exercise. I replicated the style of other tests, in this case we're testing if the pattern provided (.log) correctly ignores .log files in a directory:
func TestIsIgnored_FilenameMatch(t *testing.T) {
// Given: GitIgnore with a filename pattern
tempDir := t.TempDir()
gitignorePath := filepath.Join(tempDir, ".gitignore")
if err := os.WriteFile(gitignorePath, []byte("*.log"), 0644); err != nil {
t.Fatalf("Failed to create .gitignore: %v", err)
}
gi, err := NewGitIgnore(tempDir)
if err != nil {
t.Fatalf("Failed to create GitIgnore: %v", err)
}
// When/Then: Should match filename pattern
if !gi.IsIgnored("test.log", false) {
t.Error("Expected 'test.log' to be ignored")
}
if gi.IsIgnored("test.txt", false) {
t.Error("Expected 'test.txt' to not be ignored")
}
}
This is a very isolated example, but I found it quite unique to see how the worlds of mathematics merge in a very smooth way with programming.
- What was it like writing tests for a project you didn't create?
As I mentioned in the beginning, being go such a simple language to understand simplifies things in an incredible way. I've honestly written tests in complicated projects in C++, specifically with GTest and have written a bunch of LIT tests in LLVM, and I must say, Go is up there with Rust when it comes to having a great quality of life while writing tests.
- What do you think of CI now that you've set it up for yourself? If you did the optional challenges, talk about how that went and what you learned.
CI is something I set up before this lab, and to be honest, when developing things from scratch, I find it to be something I cannot live without. Implanting x feature and having the confidence and the security that something you added didn't break anything, it's truly amazing. I did set up a linter with Clippy, which is a core part of the Rust ecosystem. I particularly found it a little annoying to work with because it tends to be quite picky with whitespaces.
Top comments (0)