Artifacts. What should you save, and what should you leave? As I am currently working with Gitlab, I’ll be talking a bit about how Gitlab uses them, but it can still apply to other repository platforms!
What are artifacts?
Artifacts are files or directories that are a result of one of your CI/CD pipeline stages. They can be in the form of output files, configuration files, reports, or any other resource you may want to get out of the process. For example, you may have a pipeline job running a linting program and you would like to see the report. You can have that job allow you to view and download it!
Why do I need artifacts for firmware?
Most developers that use Continuous Integration (CI) are going to know artifacts fairly well, but with firmware, CI isn’t as widely used. There are a couple of reasons that you may want to incorporate artifacts. Here, I’ll tell you why I think you’re missing out if you think it isn’t useful for your firmware.
For analysis and debugging automatically
We’ve talked about this before in some of our blogs, but firmware and embedded development seem to have fallen a bit out of date as compared to web or Android/iOS dev. The tools used for these other fields can be useful for us too!
Hex files, binary files, any kinds of outputs your firmware can dream of, can be produced and analyzed through continuous integration. We mentioned viewing and downloading them, but you can also pass the artifacts from one job into others that do analysis for you! Your hex files can be automatically installed on the test rig or sent to the testing team! Your automatic documentation can be instantly uploaded to your help pages! It takes away the the clunkiness and time that may have become part of your daily routine. As engineers, our time is expensive, and any time we can save by not doing boring repetitive tasks is not only good for our sanity, but good for business.
Not as widely supported
Once you start digging in a bit to get your firmware building through CI, you might quickly find that the tools and programs you are running don’t have direct support through your CI processes, but don’t worry! I’ll let you in on how we handle these issues using EmbedOps.
How we solved this on EmbedOps, and an option that initially may take a bit of time to get started, is to setup your own personal gitlab-runner. We have done this with AWS EC2 machines as well as with local machines. Using the gitlab-runner, you can setup the exact environment you have inevitably webbed together to generate output files and analyze them.
After you’ve taken the time to set it up, and set up your artifacts, you can grab those output files and have them thrown through linting programs or others your firmware desires! Now you will have more time to get other work done! (Or grab more coffee. I won’t judge.)
Surely, since you have become convinced to throw some artifacts into your continuous integration processes in with your firmware, here is a quick look into how to add them to a build stage in gitlab’s configuration yaml (gitlab-ci.yml):
build:
stage: build
script:
- do some build things
artifacts:
name: ThatFileYouNeed
paths:
- PATH/TO/FILE.out
Now that you know that artifacts can help you too, you’ll probably want a little more information. Head over to gitlab’s documentation on job artifacts to learn everything about how they can save you time and bring your firmware process up to date.
If you want all of the benefits listed here and none of the hassle of setting them up or maintaining them, consider reaching out! At DojoFive, we have talented engineers on hand ready to help you with all aspects of your EmbedOps journey. We are always happy to help with interesting problems that need solving. You can reach out at any time on LinkedIn or through email!
