I have a repository that defines two Docker images, and has a README for documentation. These images are “expensive” to build (in terms of time and compute cycles), so I only want to build an image if relevant code has changed. I certainly don’t want to build both images just because I committed an update to the README.
How can I configure specific Circle CI jobs to run based on changes on a specific path within my repository?
I’m new to Circle CI, but so far - from browsing the docs and this forum - the answer to this question is either shrug/silence, or a hack.
To ask a more general question: is Circle CI specifically and explicitly opinionated that any commit anywhere in a repo will trigger the entire build process? Philosophically, how does Circle CI approach this scenario?
Hopefully I have simply overlooked some key documentation.
It’s a forum, things get missed. I think the idea here is that CircleCI users help each other in a volunteer capacity, which happens a bit, but not much. Building communities is hard
There are several employees that help here, but CI is a bit like web hosting - from an employee perspective, there is a blurry line between giving the right help to use the platform and doing someone else’s CI work for free
Food for thought! (Just a free tier user).
For speeding up Docker, there is a layer caching device (not free). Or you can build it yourself using a Docker registry - it’s been discussed here a few times.
I posted about this subject here. It does not use path detection; the idea here is that your Docker builds are sped up to such a degree that path detection is unnecessary.
I think path detection has been discussed. Search for “monorepo” in this forum to see some ideas on that. There is no out-of-the-box support for it, but as with all CI systems, something custom can surely be implemented.
“monorepo” was a good tip - thanks.
I suppose the answer could include: “Any commit will trigger
.circleci/config.yml, but what happens in there is up to the author.”
No worries. Just bear in mind that speeding up Docker builds is more of an established thing than monorepo filtering. However, the latter can be (sort of) done with Bash conditionals (there is still a run, but it gets a green mark in 10 seconds or so).
I don’t think CircleCi supports conditional building although I guess in a workflow you could create an “in-between” step, for example an approval step, that is a requirement for your expensive step, this way the expensive step is only executed if you manually approve.
Alternatively you could add
[ci skip] or
[skip ci] to your commit message in which case CircleCi will skip that commit.