Fix CI build for release builds
See original GitHub issue- In the configuration.properties the
otversion
key has the value “2.3+69a962e” - <del>HTML5 contains
sass
folder</del> - ODT contains
src
,test
andresources
folders - RTF contains
src
folder - docsrc contains
temp
folder
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Identify and fix broken builds with CI/CD pipelines | TechTarget
Are failed or broken builds creating CI/CD pipeline challenges? Developers can check credentials, fix flaky tests and implement alerts to ...
Read more >5 Strategies to Reduce Frontend Build Time with CI/CD
So, In this article will take you through four different strategies to optimize the front-end build time with CI/CD. 1. Using Parallel Web...
Read more >Troubleshooting CI/CD - GitLab Docs
GitLab provides several tools to help make troubleshooting your pipelines easier. This guide also lists common issues and possible solutions.
Read more >Continuous Integration - Martin Fowler
In a Continuous Integration environment you should never have a failed integration build stay failed for long. A good team should have many...
Read more >Enabling Continuous Integration with Azure Pipelines
Select the Triggers tab. These triggers enable you to automatically invoke builds on a schedule, when another build completes, or when changes ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I agree with @infotexture. I can certainly see myself wanting to extend the default DITA-OT SASS files.
Since the
sass
folder only takes up a few kilobytes, I would be inclined to include them for the benefit of those who would like to extend the defaults with their own mixins, partials, etc.That would allow web devs who are unfamiliar with DITA-OT to extend styling and simply regenerate the common CSS files using standard Sass practices, rather than requiring customization of the
org.dita.html5
plug-in.To better support that use case, we might decide to ship a Sass build file later and provide an additional
args.sass
parameter to hook into the CSS pre-processing rather than overriding styles incommonltr.css
later with a custom CSS file specified viaargs.css
— but that should be treated as a separate issue.