ceedling 1.1.10 → 1.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 828ad43a2f6d106ff54bb18fcb6bab61f3c9164f1ae7f2c2923d8739f0351696
-  data.tar.gz: d0f1bd257e32aa6c45cb1166904a124ea4f2f5bb17c6e3504a5c8b3e7b7bce28
+  metadata.gz: 1eb94c2d7bae641fd66962f23ab8ee145a73c635f0fd7a5ae5fb2d9602f2713a
+  data.tar.gz: 2a20e6e6da82880a3ba78464a872c92ccb1be79174385a806477133e116d2682
 SHA512:
-  metadata.gz: 40b9742b2c4bc7deb08a52e2281cf81b4684bbcdb08ac5b3dcffd6d0ee2af087c7cda184764938bb54bbb5b1c5e9d6fd17d822468cbc8b579667a21228917ca7
-  data.tar.gz: 67be8904bf70f79f954b13a4fcfd8b47805fc82e5a2ea3e1af7b82463759dcf08846c75638b280f19f38538a212cc91d958dcde785729377f654411c3de69ef3
+  metadata.gz: 0a5e8b807216ea64535a94e5b7b1a4b005f84ece39c5c4dad3bebf5cb0febe7236a8c8db30716baa2ffc3db7b48df8dfb2b3e7e3cced0bd851c88528f5b6773b
+  data.tar.gz: 1e46b99eba0c0fa4a8e365719688d0d643a8338ce7d01e30c5a77c918e5f0ca151c37da0959006ff13d2b8ae904da95f9be19ffb9d1ebb17c6ccbafe55760e11

data/.rspec

@@ -0,0 +1,3 @@
+-I spec/support
+-I spec/support/system
+-I spec/support/integration

data/.simplecov

@@ -0,0 +1,73 @@
+# =========================================================================
+#   Ceedling - Test-Centered Build System for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+# Shared SimpleCov configuration. The unit-test suite picks this up through
+# SimpleCov's own upward-directory-search autoload (its CWD is this repo). The
+# system-test suite's own subprocess boot (spec/support/system/simplecov_boot.rb)
+# loads this file explicitly by absolute path instead, since that subprocess's CWD
+# is a throwaway deployed project directory, not this repo, when it starts -- the
+# autoload search would walk straight past it and find nothing.
+#
+# `.simplecov` is configuration only -- SimpleCov.configure, not SimpleCov.start.
+# Calling `.start` from this file is deprecated as of SimpleCov 1.x (tracking
+# would still begin for backward compatibility, but with a nagging warning on
+# every run). Each real entry point (spec/support/spec_helper.rb,
+# spec/support/system/simplecov_boot.rb, plugins/fff/spec/spec_helper.rb) loads
+# this config, then calls the bare `SimpleCov.start` that actually begins
+# tracking, once for its own process.
+#
+# cover (rather than only reporting files a run actually happened to require)
+# means a file no test ever touches still shows up at 0% instead of being silently
+# absent from the total -- lib/, bin/, and plugins/ are what the gem actually ships
+# and what both test suites exercise; vendor/ is CMock/Unity/CException's own
+# separately tested source, not this repo's. The /spec/ and /vendor/ filters below
+# also cover the handful of plugins with their own nested spec/vendor code (e.g.
+# plugins/fff/spec/, plugins/fff/vendor/fff/), not just this repo's own top-level
+# spec/ and vendor/.
+#
+# One cover call with a brace-glob covering all three trees.
+#
+# Grouped into the same three trees as a report's own tabs, so a report reads as
+# "how well is each shipped piece covered" rather than one flat file list.
+SimpleCov.configure do
+  cover '{lib,bin,plugins}/**/*.rb'
+
+  skip '/spec/'
+  skip '/vendor/'
+
+  # Root-of-lib/ files (lib/snapshot.rb, lib/ceedling.rb, lib/version.rb) are
+  # tiny require/entry-point shims, not business logic -- anchored so it
+  # doesn't also catch lib/ceedling/**, which is exactly what should still count.
+  # No leading "/": SimpleCov 1.x's project_filename is root-relative WITHOUT
+  # one (e.g. "lib/version.rb", not "/lib/version.rb", unlike 0.22) -- an
+  # anchor expecting a leading slash never matches anything, silently.
+  skip %r{\Alib/[^/]+\.rb\z}
+
+  # A plugin's config/defaults_<plugin>.rb is a table of constant tool definitions,
+  # loaded with that plugin's configuration and holding no logic to exercise. Anchored
+  # without a leading "/" for the same reason as above.
+  skip %r{\Aplugins/[^/]+/config/defaults_[^/]+\.rb\z}
+
+  # Thin adapters over Ruby stdlib/OS calls (file_wrapper.rb, system_wrapper.rb,
+  # yaml_wrapper.rb, bin/actions_wrapper.rb, etc.) -- existing tests stub around
+  # these rather than exercise them directly, so they read as permanently
+  # low/zero coverage noise rather than a real gap.
+  #
+  # A String argument here is path-segment-aware as of SimpleCov 1.x (must
+  # appear as a whole segment between "/" boundaries) -- deliberately a bare
+  # Regexp instead, since "_wrapper" is a fragment of a segment
+  # (file_wrapper.rb), not a whole one, and needs a true substring match.
+  skip(/_wrapper/)
+
+  # Anchored to the root of each tree -- a plain substring match (e.g. 'lib/')
+  # would also catch lib/ceedling/plugins/plugin_manager.rb (a real lib/
+  # subdirectory) into the plugins group, etc. No leading "/" in the anchor,
+  # same reasoning as the skip filter above -- project_filename never has one.
+  group 'bin', %r{\Abin/}
+  group 'lib', %r{\Alib/ceedling/}
+  group 'plugins', %r{\Aplugins/}
+end

data/GIT_COMMIT_SHA

@@ -1 +1 @@
-85ec551
+47d2c5e

data/Gemfile

@@ -12,22 +12,98 @@ gem "bundler", "~> 2.5"
 # Testing tools
 gem "rspec", "~> 3.8"
 gem "rake", ">= 12", "< 14"
-gem "rr"
 gem "require_all"
 
-# `rexml` has been removed from the default gems in some Ruby versions -- needed
-# explicitly by the gcov Partials system-test cases, which parse gcovr's XML output.
-gem "rexml"
+# Test-only: spec/system/support/gcov_partials_test_cases.rb parses coverage XML.
+# rexml has been removed from the default gems bundled with some Ruby installations
+# (same category as benchmark below), so it must be declared explicitly here too.
+gem "rexml", ">= 3.2"
+
+# Dev-only: used by DependencyTracker's :full debug tier to render human-readable
+# content diffs. Soft dependency at runtime (lib/ceedling/dependencies/dependency_differ.rb
+# requires it defensively and degrades gracefully if absent) -- deliberately NOT declared in
+# ceedling.gemspec, so it is never a hard requirement for an installed release gem.
+gem "diff-lcs", "~> 1.5"
+
+# Dev-only: code coverage for CI's combined unit+system test coverage report.
+# require: false since it's only ever loaded when CEEDLING_TEST_COVERAGE is set --
+# deliberately NOT declared in ceedling.gemspec, same as diff-lcs above.
+#
+# The version gate exists to reach a significant SimpleCov feature revision.
+# SimpleCov 1.x requires Ruby >= 3.2 and gives access to modern config method names
+# (cover/skip/group) and the simplecov:disable/enable directive comments used
+# throughout .simplecov and bin/cli.rb. Benefiting from that modernization is only
+# possible by gating on Ruby version, hence the branch below.
+#
+# Coverage reporting is purely a CI mechanism, so it is deliberately confined to the
+# one leg that satisfies the version requirement: the `tests-linux` job on Ruby 3.3
+# (see ci.yml, where CEEDLING_TEST_COVERAGE is set only when matrix.ruby == '3.3').
+# No Windows or macOS leg, and no other Ruby leg, ever sets that variable, so none of
+# them load this gem at all. The ~> 0.22 fallback exists purely so `bundle install`
+# still resolves cleanly on older interpreters, not because anything in this repo
+# actually runs against it.
+if RUBY_VERSION >= '3.2'
+  gem "simplecov", "~> 1.1", require: false
+else
+  gem "simplecov", "~> 0.22", require: false
+end
+
+# Dev-only: sampling call-stack profiler for ad hoc performance investigation
+# (flame graphs of a real Ceedling build/test run). Not required by any
+# runtime code path -- deliberately NOT declared in ceedling.gemspec, same
+# as diff-lcs/simplecov above. install_if: keeps it out of ordinary `bundle
+# install` (CI included) entirely -- only `rake profile:setup` installs it,
+# by setting CEEDLING_PROFILING=true first. Gating is necessary, not just
+# tidy: its native C extension fails to build on Windows
+# (Gem::Ext::BuildError), which broke Windows CI outright when this gem was
+# briefly installed unconditionally. Whether stackprof can ever build on
+# Windows at all (even via an explicit `rake profile:setup` there) is
+# untested and unresolved -- profiling should currently be assumed
+# non-Windows-only.
+gem "stackprof", "~> 0.2", require: false, install_if: -> { ENV['CEEDLING_PROFILING'] == 'true' }
+
+# Dev-only: Ruby linting, limited to the Lint, Metrics, Security, and Performance
+# departments (see .rubocop.yml). Not required by any runtime code path --
+# deliberately NOT declared in ceedling.gemspec, same as diff-lcs/simplecov/stackprof
+# above. install_if: keeps these out of an ordinary `bundle install` so a developer
+# who never lints never pays to fetch them; `rake lint:setup` sets CEEDLING_LINT=true
+# and installs them on demand. Unlike CEEDLING_PROFILING, CI *does* set this variable
+# -- the lint job sets it at job scope because install_if: is Bundler's runtime
+# activation predicate as well as its install-time one, so `bundle exec` needs it too.
+#
+# Note install_if: governs installation and activation, not resolution: both gems and
+# their transitive dependencies appear in Gemfile.lock regardless, exactly as stackprof
+# already does. The savings are install time and bandwidth, not lockfile size.
+#
+# Both are pinned to a patch range rather than `~> 1.x`. Every RuboCop minor release
+# adds cops, which would silently change the offense set and move CI results with no
+# commit to point at. Bumping is therefore a deliberate act that lands alongside any
+# resulting .rubocop_todo.yml churn.
+gem "rubocop", "~> 1.91.0", require: false, install_if: -> { ENV['CEEDLING_LINT'] == 'true' }
+gem "rubocop-performance", "~> 1.27.0", require: false, install_if: -> { ENV['CEEDLING_LINT'] == 'true' }
+
+# Nothing here declares `erb`, and that is deliberate. Ceedling itself no longer uses
+# it at all. RSpec does: rspec-core requires `erb` at load time (configuration_options.rb)
+# without declaring a dependency on it, and that works only because `erb` is a default
+# gem, which is always requirable even under `bundle exec` and even when undeclared.
+# Verified a default gem on every Ruby Ceedling supports, through 3.5.
+#
+# If a future Ruby demotes `erb` to a bundled gem the way it did `benchmark` in 3.5,
+# `bundle exec rspec` will fail to load with `cannot load such file -- erb`. The fix is
+# a development/test-only declaration here, never a gemspec dependency, since no
+# Ceedling runtime code path requires it.
 
 # Ceedling dependencies
-gem "diy", "~> 1.1"
+#
+# `diy` is absent deliberately. Its source is vendored at vendor/diy, and
+# bin/ceedling puts that directory on the load path before requiring it, so the
+# vendored copy is what loads. Upstream has been unmaintained since 2009.
 gem "constructor", "~> 2"
 gem "thor", "~> 1.3"
 gem "deep_merge", "~> 1.2"
 
-# `erb` & `benchmark` have been removed from the default gems in some Ruby versions Ceedling supports.
-# These must be declared explicitly for plain `gem install` (non-Bundler) users to successfully span supported Ruby versions.
-gem "erb", ">= 2.2"
+# `benchmark` has been removed from the default gems in some Ruby versions Ceedling supports.
+# It must be declared explicitly for plain `gem install` (non-Bundler) users to successfully span supported Ruby versions.
 gem "benchmark", ">= 0.3"
 
 gem "unicode-display_width", "~> 3.1"

data/Gemfile.lock

@@ -1,18 +1,25 @@
 GEM
   remote: http://rubygems.org/
   specs:
+    ast (2.4.3)
     benchmark (0.5.0)
     constructor (2.0.0)
     deep_merge (1.2.2)
     diff-lcs (1.6.2)
-    diy (1.1.2)
-      constructor (>= 1.0.0)
-    erb (2.2.0)
+    json (3.0.2)
+    language_server-protocol (3.17.0.6)
+    lint_roller (1.1.0)
     parallel (1.28.0)
+    parser (3.3.12.0)
+      ast (~> 2.4.1)
+      racc
+    prism (1.9.0)
+    racc (1.8.1)
+    rainbow (3.1.1)
     rake (13.2.1)
+    regexp_parser (2.13.1)
     require_all (3.0.0)
     rexml (3.4.4)
-    rr (3.1.2)
     rspec (3.13.2)
       rspec-core (~> 3.13.0)
       rspec-expectations (~> 3.13.0)
@@ -26,6 +33,27 @@ GEM
       diff-lcs (>= 1.2.0, < 2.0)
       rspec-support (~> 3.13.0)
     rspec-support (3.13.7)
+    rubocop (1.91.0)
+      json (>= 2.3)
+      language_server-protocol (~> 3.17.0.2)
+      lint_roller (~> 1.1.0)
+      parallel (>= 1.10)
+      parser (>= 3.3.0.2)
+      rainbow (>= 2.2.2, < 4.0)
+      regexp_parser (>= 2.9.3, < 3.0)
+      rubocop-ast (>= 1.49.0, < 2.0)
+      ruby-progressbar (~> 1.7)
+      unicode-display_width (>= 2.4.0, < 4.0)
+    rubocop-ast (1.50.0)
+      parser (>= 3.3.7.2)
+      prism (~> 1.7)
+    rubocop-performance (1.27.0)
+      lint_roller (~> 1.1)
+      rubocop (>= 1.89.0, < 2.0)
+      rubocop-ast (>= 1.47.1, < 2.0)
+    ruby-progressbar (1.13.0)
+    simplecov (1.1.1)
+    stackprof (0.2.28)
     thor (1.5.0)
     unicode-display_width (3.2.0)
       unicode-emoji (~> 4.1)
@@ -44,14 +72,16 @@ DEPENDENCIES
   bundler (~> 2.5)
   constructor (~> 2)
   deep_merge (~> 1.2)
-  diy (~> 1.1)
-  erb (>= 2.2)
+  diff-lcs (~> 1.5)
   parallel (~> 1.26)
   rake (>= 12, < 14)
   require_all
-  rexml
-  rr
+  rexml (>= 3.2)
   rspec (~> 3.8)
+  rubocop (~> 1.91.0)
+  rubocop-performance (~> 1.27.0)
+  simplecov (~> 1.1)
+  stackprof (~> 0.2)
   thor (~> 1.3)
   unicode-display_width (~> 3.1)
 

data/README.md

@@ -1,42 +1,6 @@
-Ceedling ![CI](https://github.com/ThrowTheSwitch/Ceedling/workflows/CI/badge.svg)
+[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15117/badge)](https://www.bestpractices.dev/projects/15117) [![Docs](https://img.shields.io/badge/Docs-white?logo=materialformkdocs&link=https%3A%2F%2Fdocs.throwtheswitch.org%2FCeedling%2F)](https://docs.throwtheswitch.org/Ceedling/) [![Discourse](https://img.shields.io/badge/Discourse-purple?logo=discourse&link=https%3A%2F%2Fthrowtheswitch.discourse.group)](https://throwtheswitch.discourse.group) ![CI](https://github.com/ThrowTheSwitch/Ceedling/workflows/CI/badge.svg)
 ========
 
-**Ceedling 1.1.10** is the latest and greatest.
-
-See [_Release Notes_][release-notes], [_Changelog_](docs/Changelog.md), 
-[_Breaking Changes_][breaking-changes], and [_Known Issues_][known-issues].
-
-See [🚀 Getting Started](#-getting-started) for installation and new 
-project set up.
-
-**New goodies in 1.1.x:**
-* A [Partial][partials-docs] allows a test to mix mocked and real functions 
-from the same source module in a single test file and enables testing of 
-`static` and `inline` functions without modifying source code.
-* Ceedling is now complemented by a full, searchable [documentation site][ceedling-docs-site]
-  available both online and as a local bundle exported from Ceedling’s 
-  command line.
-* A new [Discourse community forum](https://throwtheswitch.discourse.group) to 
-  supersede the old, spammy Google Group and handful of disparate support channels.
-* More and expanded [example projects][example-projects].
-* New stock plugins for [Valgrind memory checking][valgrind-plugin] and 
-[Cppcheck static analysis][cppcheck-plugin].
-* The [GCov plugin][gcov-plugin]:
-   * Now supports coverage reports for all sources.
-   * Adds support for Modified Condition / Decision Coverage.
-* Mixins improvements including an option for [inline YAML at the command line][mixins-inline-yaml].
-* Ceedling’s test preprocessing is once again compatible with Unity’s 
-  parameterized test cases (support was temporarily removed with 1.0.0).
-* Incorporates the latest updates to [CMock] and [Unity].
-
-[partials-docs]: https://throwtheswitch.github.io/Ceedling/1.1.0/testing-guide/partials/
-[example-projects]: https://throwtheswitch.github.io/Ceedling/latest/getting-started/example-projects/
-[ceedling-docs-site]: https://throwtheswitch.github.io/Ceedling/
-[valgrind-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/valgrind/
-[cppcheck-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/cppcheck/
-[gcov-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/gcov/
-[mixins-inline-yaml]: https://throwtheswitch.github.io/Ceedling/latest/configuration/mixins/?h=mixins#-mixin-command-line-flags
-
 # 🌱 Ceedling is a handy-dandy build system for C projects
 
 ## Developer-friendly release _and_ test builds
@@ -74,6 +38,55 @@ Ceedling’s features support all types of C development from low-level embedded
 to enterprise systems. No tool is perfect, but Ceedling can do a whole lot to 
 help you and your team produce quality software.
 
+## Ceedling 1.2.1 is the latest and greatest
+
+See [_Changelog_](docs/Changelog.md), [_Release Notes_][release-notes], [_Breaking Changes_][breaking-changes], and [_Known Issues_][known-issues].
+
+**New goodies in 1.2.0:**
+* **[Delta builds][delta-builds]** have been restored after a temporary hiatus following a major refactoring for 1.0.0. A [delta build][delta-build-overview] is simply a build run that only performs regeneration, compilation, or linking as needed because of changed files. [Delta builds][delta-builds] are automatic with no configuration and complement [parallel builds][parallel-builds] introduced in 1.0.0 for build time speedups.
+* **`#include` relative paths & duplicate filename disambiguation**. Ceedling now fully supports [relative paths in `#include` directives][same-named-files] and [`TEST_SOURCE_FILE()` build directive macros][test-source-file]. Ceedling is now also able to distinguish files of the same name using paths in the preceding and [at the command line][test-path-task] to distinguish test files of the same name (e.g. `ceedling test:foo/file` vs. `ceedling test:bar/file`).
+* **Multiple file extensions per file type.** You may now provide a list of file types via [`:extensions`][extension-config] to gather files into your project’s build. For instance, the extensions `.c` and `.cc` can now both be used together to collect all source file in your project.
+* **Shuffled test order.** Ceedling now supports [Unity’s][unity-framework] randomized test case ordering (via a [`:unity` configuration setting][shuffle-tests]). [Delta builds][delta-builds] automatically adjust to always rerun test executables so test case ordering is shuffled.
+* The **[`TEST_SOURCE_FILE()` build directive macro][test-source-file-subtractive]** can now be used to remove source files from a test executable build. This can be handy in overriding [Ceedling’s conventions][header-source-convention] for associating source files with a test executable if your project structure does not match up with Ceedling’s conventions.
+* The **new [Sanitize plugin][sanitize-plugin]** builds and runs tests with ASan, UBSan, and LeakSanitizer, naming each finding where a test fails and writing text, JSON, and SARIF reports.
+* The **[build warnings]**, **[JUnit report]**, **[IDE integration]**, **[GoogleTest report]**, **[module generator]**, and **[dependencies]** plugins all received numerous bug fixes and feature expansions.
+* **[Bullseye code coverage plugin][bullseye-plugin]** re-enabled and modernized (disabled since 1.0.0).
+* **Dedicated mocks and test runner generation build tasks.** It is now possible to run the test build pipeline only up through generating mocks or test runners without running the rest of a build using `ceedling gen:mocks:<test>` and `ceedling gen:test_runner:<test>` mirroring the convention of `test:` tasks.
+* Ceedling prerelease and release builds now automatically **[generate Software Bills of Material][sbom-docs]** (SBOMs) and attach them to GitHub pre/releases along with the final Ruby gem.
+
+**Goodness introduced in 1.1.0:**
+* A [Partial][partials-docs] allows a test to mix mocked and real functions 
+from the same source module in a single test file and enables testing of 
+`static` and `inline` functions without modifying source code.
+* Ceedling is now complemented by a full, searchable [documentation site][ceedling-docs-site]
+  available both online and as a local bundle exported from Ceedling’s 
+  command line.
+* A new [Discourse community forum][forums] to 
+  supersede the old, spammy Google Group and handful of disparate support channels.
+
+[delta-builds]: https://docs.throwtheswitch.org/Ceedling/1.2.0/getting-started/builds/
+[delta-build-overview]: https://docs.throwtheswitch.org/Ceedling/1.2.0/getting-started/builds/#delta-build-overview
+[parallel-builds]: https://docs.throwtheswitch.org/Ceedling/1.2.0/configuration/parallel-builds/
+[same-named-files]: https://docs.throwtheswitch.org/Ceedling/1.2.0/testing-guide/conventions/#distinguishing-same-named-files
+[test-source-file]: https://docs.throwtheswitch.org/Ceedling/1.2.0/testing-guide/build-directives/#test_source_file
+[test-path-task]: https://docs.throwtheswitch.org/Ceedling/1.2.0/getting-started/command-line/#ceedling-testpath
+[extension-config]: https://docs.throwtheswitch.org/Ceedling/1.2.0/configuration/reference/extension/
+[unity-framework]: https://docs.throwtheswitch.org/Ceedling/1.2.0/overview/tools-and-frameworks/#unity
+[shuffle-tests]: https://docs.throwtheswitch.org/Ceedling/1.2.0/configuration/reference/unity/#shuffle_tests
+[test-source-file-subtractive]: https://docs.throwtheswitch.org/Ceedling/1.2.0/testing-guide/build-directives/#test_source_file-subtractive-notation
+[header-source-convention]: https://docs.throwtheswitch.org/Ceedling/1.2.0/testing-guide/build-directives/#test_source_file-the-headersource-convention
+[build warnings]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/report-build-warnings-log/
+[JUnit report]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/report-tests-log-factory/#junit-xml-format
+[IDE integration]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/report-tests-ide-stdout/
+[GoogleTest report]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/report-tests-gtestlike-stdout/
+[module generator]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/module-generator/
+[dependencies]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/dependencies/
+[sanitize-plugin]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/sanitize/
+[bullseye-plugin]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/bullseye/
+[sbom-docs]: https://docs.throwtheswitch.org/Ceedling/latest/project/sbom/
+[partials-docs]: https://docs.throwtheswitch.org/Ceedling/1.1.0/testing-guide/partials/
+[ceedling-docs-site]: https://docs.throwtheswitch.org/Ceedling/
+
 ## Supporting this work
 
 Ceedling and its complementary [ThrowTheSwitch] pieces and parts are and always 
@@ -129,7 +142,7 @@ library builds & dependency management, and more.
 [TDD]: http://en.wikipedia.org/wiki/Test-driven_development
 [test-doubles]: https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da
 [FFF]: https://github.com/meekrosoft/fff
-[FFF-plugin]: https://throwtheswitch.github.io/Ceedling/latest/plugins/fff/
+[FFF-plugin]: https://docs.throwtheswitch.org/Ceedling/latest/plugins/fff/
 
 <br/>
 
@@ -160,6 +173,13 @@ Prereleases are ephemeral and will be pulled as development continues or bugs ar
 
 Prereleases are not officially supported, but feedback through submitting issues is very much welcome. As much help as is practical will be offered to support those exercising prereleases.
 
+## Software Bill of Materials
+Every release publishes a Software Bill of Materials in both CycloneDX and SPDX formats. Each document is attached to its release alongside the .gem file and is signed against it.
+
+The documents describe the Ceedling gem as distributed. They list what ships inside it — Unity, CMock, CException, and more — plus the Ruby dependencies a user installs. They do not describe the C code Ceedling builds for you, and they cannot describe the external tools an enabled plugin needs.
+
+See [Software Bill of Materials](https://docs.throwtheswitch.org/Ceedling/latest/project/sbom/) for what is included, how to verify a signature, and why a version-specific download link is the reliable one.
+
 <br/>
 
 # 🙋‍♀️ Need Help? Want to Help?
@@ -431,12 +451,12 @@ The [Agile Embedded Podcast][ae-podcast] includes an [episode on Ceedling][ceedl
 ## Ceedling docs
 
 * **_[Ceedling’s documentation site][ceedling-docs-site]_** contains everything you need to know to run Ceedling. It also references and links to the documentation of the projects, _Unity_ and _CMock_, that Ceedling weaves together into your test and release builds.
-* **[Release Notes][release-notes]**, **[Breaking Changes][breaking-changes]**, **[Known Issues][known-issues]**, and **[Changelog][changelog]** can be found in the **[docs/](docs/)** directory along with a number of guides (PDFs).
+* **[Release Notes][release-notes]**, **[Breaking Changes][breaking-changes]**, **[Known Issues][known-issues]**, and **[Changelog][changelog]** can be found in the **[docs/](docs/)** directory.
 * The **[Plugins section][ceedling-docs-plugins]** of Ceedling’s documentation lists all of Ceedling’s built-in plugins providing overviews and links to their documentation.
 
 _Note:_ Check the [Release Notes][release-notes] for a “cheat sheet” illustrating project configuration option changes for new releases in the form of a Ceedling project YAML configuration file. This may be especially useful to those already familiar with the tool wanting to update to the latest and greatest as quickly as possible.
 
-[ceedling-docs-plugins]: https://throwtheswitch.github.io/Ceedling/latest/plugins/
+[ceedling-docs-plugins]: https://docs.throwtheswitch.org/Ceedling/latest/plugins/
 
 ## Library and courses
 
@@ -466,7 +486,7 @@ Matt Chernosky’s **[detailed tutorial][tutorial]** demonstrates using Ceedling
 
 👀 See the **_[Quick Start][ceedling-docs-quick-start]_** section of Ceedling’s documentation site.
 
-[ceedling-docs-quick-start]: https://throwtheswitch.github.io/Ceedling/latest/getting-started/quick-start/
+[ceedling-docs-quick-start]: https://docs.throwtheswitch.org/Ceedling/latest/getting-started/quick-start/
 
 ## The basics
 
@@ -487,7 +507,6 @@ Matt Chernosky’s **[detailed tutorial][tutorial]** demonstrates using Ceedling
    ```shell
    > ceedling test:all release
    ```
-
 ### Local installation of the .gem file downloaded from this repo
 
 If you are working with prerelease versions of Ceedling or some other off-the-beaten-path installation scenario, you may want to directly install the Ceedling .gem file attached to any of the Github releases. No problem.
@@ -598,8 +617,8 @@ Or, use Ceedling’s built-in `examples` & `example` commands to extract a sampl
 
 See the [configuration section][ceedling-docs-config] of Ceedling’s documentation for way more details on your project configuration options than we can provide here.
 
-[example-config-file]: assets/project.yml
-[ceedling-docs-config]: https://throwtheswitch.github.io/Ceedling/latest/configuration/
+[example-config-file]: assets/features/project.yml
+[ceedling-docs-config]: https://docs.throwtheswitch.org/Ceedling/latest/configuration/
 
 ## Using Ceedling’s command line (and related)
 
@@ -740,4 +759,4 @@ the **[Ceedling development workflow][ceedling-dev-workflow]** guide.
 
 [coding-standard]: docs/ThrowTheSwitchCodingStandard.md
 [pr-checklist]: docs/CeedlingPullRequestChecklist.md
-[ceedling-dev-workflow]: https://throwtheswitch.github.io/Ceedling/latest/development/workflow/
+[ceedling-dev-workflow]: https://docs.throwtheswitch.org/Ceedling/latest/development/workflow/