Open dustinleblanc opened 8 months ago
Tracking internally as FEAT-1348
One of our developers wondered if you could use a CI "cache" to store and reuse the theme assets? https://circleci.com/docs/caching/
@namespacebrian entirely possible we could try to configure something like that, however, I have manually tested this concept on our project (by just copying the steps out of the orb to our own project and modifying them) and it does seem to be working as I expect. We can conditionally build our theme only when it has changed, and the theme assets will remain in place on Pantheon if no new theme build is present, but be updated when we make changes to the theme itself.
Thinking about my request this morning, instead of an environment variable, it would probably make sense to implement as a parameter with a default value that users can override when pulling in the orb.
If the Pantheon team would be interested in adding this feature, I'd be happy to provide a pull request to implement, including documentation to show how this can be used to conditionally build the theme assets (based on our own code). From my experience, this saves about 1.5 minutes off our builds when no theme is compiled (which will vary for folks depending on the complexity of their theme, we're using a customized Emulsify).
Thanks!
Consulted @kporras07, as I am not well versed in build tools nor do I fully understand the issue, but Kevin said "I think that makes sense. As long as we keep default bahavior, I think I like it."
If you send us a PR, we will review it and merge or request changes. ☺️
Just a heads up, there is an open PR for this from last month
We're working through some optimization steps to try to bring down our build times on CI builds, and one thing we're messing with is the concept of only building our theme when the theme files have changed, which could save us two minutes off many builds. Reviewing the orb code, I think the
--delete
in this line is what is blowing away our compiled theme assets when new builds happen. Could we look into making that behavior configurable while keeping the default? Perhap use an environment variable to determine whether or not to delete files, or a way to flag in additional exclude directories, etc would allow us to not disrupt current users but add in some flexibility here?