deploy: cc799a9

CONTRIBUTING.html

@@ -186,8 +186,8 @@ <h1 id="how-to-contribute"><a class="header" href="#how-to-contribute">How to co
 All pull requests should be targeted to the <code>main</code> branch outside of exceptional circumstances.</p>
 <h2 id="testing"><a class="header" href="#testing">Testing</a></h2>
 <p>As many tests as possible should run with the standard <code>go test</code> invocations.
-Adding the special tag <code>integration</code> (e.g. <code>go test -tags integration ./...</code>) will also run &quot;integration&quot; tests.
-The project interprets &quot;integration&quot; tests to mean any test that would need external resources, such as:</p>
+Adding the special tag <code>integration</code> (e.g. <code>go test -tags integration ./...</code>) will also run "integration" tests.
+The project interprets "integration" tests to mean any test that would need external resources, such as:</p>
 <ul>
 <li>External web servers</li>
 <li>External network access</li>
@@ -208,14 +208,14 @@ <h2 id="pull-requests"><a class="header" href="#pull-requests">Pull Requests</a>
 <li>Commit messages having a properly formed subject</li>
 <li>Go modules being tidied</li>
 </ul>
-<p>Please use the &quot;draft&quot; option if the branch is not ready.
-Please enable the &quot;allow edits by maintainers&quot; option.</p>
+<p>Please use the "draft" option if the branch is not ready.
+Please enable the "allow edits by maintainers" option.</p>
 <p>The maintainers may rebase, push, and merge contributors' branches.
 This may necessitate doing a <code>git reset &lt;remote&gt;/&lt;branch&gt;</code> to update a local branch.</p>
 <h2 id="conventions"><a class="header" href="#conventions">Conventions</a></h2>
-<p>Git commits should be formatted like &quot;subject: summary&quot; and avoid going over 80 characters per line.
-The &quot;subject&quot; is usually the package affected by the commit (like <code>jar</code> or <code>rhel</code> -- the relative path isn't needed) but sometimes a broader category (like <code>docs</code>, <code>all</code>, or <code>cicd</code>) is OK.</p>
-<p>All the helper scripts should handle the &quot;normal&quot; convention (<code>origin</code> is <code>quay/claircore</code> and <code>fork</code> is one's personal fork) and the &quot;British&quot; convention (<code>origin</code> is one's personal fork and <code>upstream</code> is <code>quay/claircore</code>).</p>
+<p>Git commits should be formatted like "subject: summary" and avoid going over 80 characters per line.
+The "subject" is usually the package affected by the commit (like <code>jar</code> or <code>rhel</code> -- the relative path isn't needed) but sometimes a broader category (like <code>docs</code>, <code>all</code>, or <code>cicd</code>) is OK.</p>
+<p>All the helper scripts should handle the "normal" convention (<code>origin</code> is <code>quay/claircore</code> and <code>fork</code> is one's personal fork) and the "British" convention (<code>origin</code> is one's personal fork and <code>upstream</code> is <code>quay/claircore</code>).</p>
 <p>More detailed contributor documentation can be found in <a href="https://quay.github.io/claircore/contributor.html">the project documentation</a>.</p>
 
                     </main>

concepts/matcher_architecture.html

@@ -211,7 +211,7 @@ <h1 id="matcher-architecture"><a class="header" href="#matcher-architecture">Mat
 <p>Once each Matcher returns the set of vulnerabities, Libvuln will merge the results into a VulnerabilityReport and return this to the client.</p>
 <h2 id="http-resources"><a class="header" href="#http-resources">HTTP Resources</a></h2>
 <p><em><strong>NOTE</strong></em>: Remote matchers are being considered for removal.</p>
-<p>&quot;Remote matchers&quot; may make HTTP requests during the matcher flow.
+<p>"Remote matchers" may make HTTP requests during the matcher flow.
 These requests are time-bound and errors are not reported.
 The following are the URLs used.</p>
 

contributor/changelog.html

@@ -207,7 +207,7 @@ <h3 id="helper-scripts"><a class="header" href="#helper-scripts">Helper scripts<
 <h3 id="formatting"><a class="header" href="#formatting">Formatting</a></h3>
 <p>Broadly, changelog entries should be formatted like commit messages without any
 trailers. Entries are turned into list items, with the subject being the bullet
-point and the body of the entry being the &quot;body&quot; of the item, or hidden behind
+point and the body of the entry being the "body" of the item, or hidden behind
 <code>details</code> elements when using HTML-enabled output.</p>
 <p>The entries are almost always rendered as markdown, so using minimal markdown is
 OK. Anything requiring excessive markdown is probably better served as

contributor/logging.html

@@ -191,7 +191,7 @@ <h2 id="how-to-log"><a class="header" href="#how-to-log">How to Log</a></h2>
 <h3 id="adding-context"><a class="header" href="#adding-context">Adding Context</a></h3>
 <p>In a function, use <code>zlog</code> to add key-value pairs of any relevant context:</p>
 <pre><code class="language-go">	ctx = zlog.ContextWithValues(ctx,
-		&quot;component&quot;, &quot;Example.Logger&quot;)
+		"component", "Example.Logger")
 </code></pre>
 <p>Alternatively, the <code>go.opentelemetry.io/otel/baggage</code> package can be used for
 more explicit control around the baggage values.</p>
@@ -201,17 +201,17 @@ <h4 id="constant-messages"><a class="header" href="#constant-messages">Constant
 is to <em>not</em> use <code>Msgf</code>. Any variable data should be set as key-value pairs on
 the Event object.</p>
 <p>For example, don't do this:</p>
-<pre><code class="language-go">	zlog.Info(ctx).Msgf(&quot;done at: %v&quot;, time.Now())
+<pre><code class="language-go">	zlog.Info(ctx).Msgf("done at: %v", time.Now())
 </code></pre>
 <p>Do this instead:</p>
 <pre><code class="language-go">	zlog.Info(ctx).
-		Time(&quot;time&quot;, time.Now()).
-		Msgf(&quot;done&quot;)
+		Time("time", time.Now()).
+		Msgf("done")
 </code></pre>
 <h4 id="grammar"><a class="header" href="#grammar">Grammar</a></h4>
 <p>When noting the change during a chunk of work, make sure that the
 log messages scan as visually similar. Usually, this means formatting messages
-into &quot;${process} ${event}&quot;. For example:</p>
+into "${process} ${event}". For example:</p>
 <pre><code>frob start
 frob initialized
 frob ready

getting_started/libindex_usage.html

@@ -190,7 +190,7 @@ <h1 id="libindex-usage"><a class="header" href="#libindex-usage">Libindex Usage<
 <h2 id="usage"><a class="header" href="#usage">Usage</a></h2>
 <p>Libindex is runtime constructed via the <code>libindex.New</code> method. New requires an <code>libindex.Opts</code> struct.</p>
 <h3 id="options"><a class="header" href="#options">Options</a></h3>
-<pre><code>package libindex // import &quot;github.com/quay/claircore/libindex&quot;
+<pre><code>package libindex // import "github.com/quay/claircore/libindex"
 
 type Options struct {
 	// Store is the interface used to persist and retrieve results of indexing.
@@ -237,7 +237,7 @@ <h3 id="options"><a class="header" href="#options">Options</a></h3>
 <p>Store is required needs to be an object that satisfies the indexer.Store interface.</p>
 <p>Locker is required and needs to satisfy the LockSource interface.</p>
 <p>FetchArena is required and needs to satify the FetchArena interface.</p>
-<p>Providing a nil &quot;Ecosystems&quot; slice will supply the default set, instructing
+<p>Providing a nil "Ecosystems" slice will supply the default set, instructing
 Libindex to index for all supported content in a layer, and is typically
 desired.</p>
 <h3 id="construction"><a class="header" href="#construction">Construction</a></h3>
@@ -269,10 +269,10 @@ <h3 id="indexing"><a class="header" href="#indexing">Indexing</a></h3>
 	}
 </code></pre>
 <p>The Index method will block until an claircore.IndexReport is returned.  The
-context should be bound to some valid lifetime such as a request. </p>
+context should be bound to some valid lifetime such as a request.</p>
 <p>As the Indexer works on the manifest it will update its database throughout the
-process.  You may view the status of an index report via the &quot;IndexReport&quot;
-method. </p>
+process.  You may view the status of an index report via the "IndexReport"
+method.</p>
 <pre><code class="language-go">	ir, ok, err := lib.IndexReport(ctx, m.Hash)
 	if err != nil {
 		panic(err)
@@ -281,7 +281,7 @@ <h3 id="indexing"><a class="header" href="#indexing">Indexing</a></h3>
 <p>Libindex performs its work incrementally and saves state as it goes along. If
 Libindex encounters an intermittent error during the index (for example, due to
 network failure while fetching a layer), when the manifest is resubmitted only
-the layers not yet indexed will be fetched and processed. </p>
+the layers not yet indexed will be fetched and processed.</p>
 <h3 id="state"><a class="header" href="#state">State</a></h3>
 <p>Libindex treats layers as content addressable. Once a layer identified by a
 particular hash is indexed its contents are definitively known. A request to
@@ -320,12 +320,12 @@ <h3 id="affectedmanifests"><a class="header" href="#affectedmanifests">AffectedM
 	}
 	for manifest, vulns := range affected.VulnerableManifests {
 		for _, vuln := range vulns {
-			fmt.Printf(&quot;vuln affecting manifest %s: %+v&quot;, manifest, vuln)
+			fmt.Printf("vuln affecting manifest %s: %+v", manifest, vuln)
 		}
 	}
 </code></pre>
 <p>The slice of vulnerabilities returned for each manifest hash will be sorted by
-<code>claircore.NormalizedSeverity</code> in &quot;most severe&quot; descending order.</p>
+<code>claircore.NormalizedSeverity</code> in "most severe" descending order.</p>
 
                     </main>
 

getting_started/libvuln_usage.html

@@ -185,12 +185,12 @@ <h1 id="libvuln-usage"><a class="header" href="#libvuln-usage">Libvuln Usage</a>
 <p>Libvuln is the Go package responsible for keeping the database of
 vulnerabilities consistent, matching container image contents with
 vulnerabilities, and reporting diffs between updates of the same security
-database. </p>
+database.</p>
 <h2 id="usage"><a class="header" href="#usage">Usage</a></h2>
 <p><code>Libvuln</code> is runtime constructed via the <code>libvuln.New</code> method. <code>New</code> requires a
 <code>libvuln.Opts</code> struct.</p>
 <h3 id="options"><a class="header" href="#options">Options</a></h3>
-<pre><code>package libvuln // import &quot;github.com/quay/claircore/libvuln&quot;
+<pre><code>package libvuln // import "github.com/quay/claircore/libvuln"
 
 type Options struct {
 	// Store is the interface used to persist and retrieve vulnerabilites
@@ -211,15 +211,15 @@ <h3 id="options"><a class="header" href="#options">Options</a></h3>
 	// If nil all default UpdaterSets will be used.
 	//
 	// The following sets are supported:
-	// &quot;alpine&quot;
-	// &quot;aws&quot;
-	// &quot;debian&quot;
-	// &quot;oracle&quot;
-	// &quot;photon&quot;
-	// &quot;pyupio&quot;
-	// &quot;rhel&quot;
-	// &quot;suse&quot;
-	// &quot;ubuntu&quot;
+	// "alpine"
+	// "aws"
+	// "debian"
+	// "oracle"
+	// "photon"
+	// "pyupio"
+	// "rhel"
+	// "suse"
+	// "ubuntu"
 	UpdaterSets []string
 	// A list of out-of-tree updaters to run.
 	//
@@ -234,15 +234,15 @@ <h3 id="options"><a class="header" href="#options">Options</a></h3>
 	// If nil all default Matchers will be used
 	//
 	// The following names are supported by default:
-	// &quot;alpine&quot;
-	// &quot;aws&quot;
-	// &quot;debian&quot;
-	// &quot;oracle&quot;
-	// &quot;photon&quot;
-	// &quot;python&quot;
-	// &quot;rhel&quot;
-	// &quot;suse&quot;
-	// &quot;ubuntu&quot;
+	// "alpine"
+	// "aws"
+	// "debian"
+	// "oracle"
+	// "photon"
+	// "python"
+	// "rhel"
+	// "suse"
+	// "ubuntu"
 	MatcherNames []string
 
 	// Config holds configuration blocks for MatcherFactories and Matchers,
@@ -323,14 +323,14 @@ <h3 id="updates-api"><a class="header" href="#updates-api">Updates API</a></h3>
 <p>In this getting started guide, we will only cover the two methods most
 interesting to new users.</p>
 <h4 id="updateoperations"><a class="header" href="#updateoperations">UpdateOperations</a></h4>
-<p>This API provides a list of recent update operations performed by implemented updaters. 
-The <code>UpdateOperation</code> slice returned will be sorted by latest timestamp descending. </p>
+<p>This API provides a list of recent update operations performed by implemented updaters.
+The <code>UpdateOperation</code> slice returned will be sorted by latest timestamp descending.</p>
 <pre><code class="language-go">	ops, err := lib.UpdateOperations(ctx, `updater`)
 	if err != nil {
 		panic(err)
 	}
 	for updater, ops := range ops {
-		fmt.Printf(&quot;ops for updater %s, %+v&quot;, updater, ops)
+		fmt.Printf("ops for updater %s, %+v", updater, ops)
 	}
 </code></pre>
 <h4 id="updatediff"><a class="header" href="#updatediff">UpdateDiff</a></h4>
@@ -344,13 +344,13 @@ <h4 id="updatediff"><a class="header" href="#updatediff">UpdateDiff</a></h4>
 		panic(err)
 	}
 	for upd, ops := range ops {
-		fmt.Printf(&quot;updater: %v&quot;, upd)
+		fmt.Printf("updater: %v", upd)
 		diff, err := lib.UpdateDiff(ctx, ops[1].Ref, ops[0].Ref)
 		if err != nil {
 			panic(err)
 		}
 		for _, vuln := range diff.Added {
-			fmt.Printf(&quot;vuln %+v added in %v&quot;, vuln, diff.Cur.Ref)
+			fmt.Printf("vuln %+v added in %v", vuln, diff.Cur.Ref)
 		}
 	}
 </code></pre>