Merge pull request #297 from uoregon-libraries/release/v4.3.0

Release/v4.3.0

CHANGELOG.md

@@ -34,6 +34,66 @@ Brief description, if necessary
 ### Migration
 -->
 
+## v4.3.0
+
+This one goes out to the devs I love. This one goes out to the devs I've left
+behind.
+
+Oh also there are a handful of nice fixes for non-devs.
+
+This time I'm splitting up the changelog by dev vs. normal person since most NCA
+users won't care about dev changes.
+
+### Regular people
+
+#### Changed
+
+- The issue queue functionality that automatically moves scanned issues has
+  been improved to not log critical errors when an issue has a pending job
+  associated with it. Heavy workloads and/or slow filesystems can take hours to
+  get huge scanned issues into NCA, and it's not an error to simply have a job
+  that hasn't started yet.
+- The batch queue command-line app will no longer allow issues that are tied to
+  unvalidated titles into a batch. This means that a title *must* have a valid
+  LCCN that exists elsewhere (usually Chronicling America or your production
+  ONI site).
+  - Batching a title that has an invalid LCCN is almost always a mistake, as ONI
+    won't be able to ingest it, so this shouldn't affect many people in practice.
+
+#### Migration
+
+- If you use titles without MARC records somehow, you'll need to either start
+  generating valid MARC records or else manually edit the database in NCA to
+  flag titles as having been validated. *This is not recommended*, and therefore
+  there will be no instructions for doing so.
+
+### Devs
+
+#### Added
+
+- New test recipe created to specifically test that queue-batches properly
+  ignores titles with unvalidated LCCNs
+
+#### Changed
+
+- The docker build is now based on RockyLinux 9 to match UO's production setup
+  more closely. It's still recommened that you use a local development setup,
+  and of course for production docker-compose isn't a great idea, but it's
+  helpful to test things quickly and validate a new environment (in this case
+  RockyLinux).
+  - The build process is now *significantly* simpler. You can see the image
+    definition yourself in `docker/Dockerfile-app`, but the gist is that we no
+    longer compile a patched version of poppler, nor install openjpeg2 tools
+    from source.
+- The docker build forcibly overwrites the settings file's SFTPGo API key on
+  *every run*. This eases dev / testing in some situations, but again makes it
+  a bad idea to use docker in production.
+- The docker override example file is a little smarter: "bin" is not mounted
+  inside the container, as that is the cause of many a headache; and
+  "/mnt/news" is not assumed to exist on the host
+- Various minor fixes to things only VSCode seemed annoyed about. VSCode users
+  should have a much easier time working on NCA. Party time? 🥳
+
 ## v4.2.0
 
 It's all about the batches. And jobs in general. Oh, and docs. Oh, right, and a

docs/index.xml

@@ -94,7 +94,7 @@ Provision a real record, including things like an LCCN This is a must for us, ot
       <guid>https://uoregon-libraries.github.io/newspaper-curation-app/setup/installation/</guid>
       <description>Development If you&amp;rsquo;re developing on NCA, installation will differ from standing up a production server. Please see our Development Guide.
 Preliminary Setup Manual installation has several prerequisites:
-Poppler Utils for PDF processing OpenJPEG 2 + command-line tools for JP2 generation The command-line tools will probably need to be manually compiled to support converting PNG files. Most distributions of Linux don&amp;rsquo;t have this by default, hence the need to manually compile. A recent version of GhostScript - 10+ is recommended GraphicsMagick MariaDB A IIIF server capable of handling tiled JP2 files without a ton of overhead (e.</description>
+Poppler Utils for PDF processing OpenJPEG 2 + command-line tools for JP2 generation GhostScript GraphicsMagick MariaDB A IIIF server capable of handling tiled JP2 files without a ton of overhead (e.g., RAIS) Apache/nginx for authentication as well as proxying to NCA and the IIIF server Please note: The easiest way to get a quick demo / test setup of NCA is via our Docker configuration / setup:</description>
     </item>
 
     <item>

docs/setup/index.xml

@@ -34,7 +34,7 @@ Somebody will want to monitor the output from the various automated processes, s
       <guid>https://uoregon-libraries.github.io/newspaper-curation-app/setup/installation/</guid>
       <description>Development If you&amp;rsquo;re developing on NCA, installation will differ from standing up a production server. Please see our Development Guide.
 Preliminary Setup Manual installation has several prerequisites:
-Poppler Utils for PDF processing OpenJPEG 2 + command-line tools for JP2 generation The command-line tools will probably need to be manually compiled to support converting PNG files. Most distributions of Linux don&amp;rsquo;t have this by default, hence the need to manually compile. A recent version of GhostScript - 10+ is recommended GraphicsMagick MariaDB A IIIF server capable of handling tiled JP2 files without a ton of overhead (e.</description>
+Poppler Utils for PDF processing OpenJPEG 2 + command-line tools for JP2 generation GhostScript GraphicsMagick MariaDB A IIIF server capable of handling tiled JP2 files without a ton of overhead (e.g., RAIS) Apache/nginx for authentication as well as proxying to NCA and the IIIF server Please note: The easiest way to get a quick demo / test setup of NCA is via our Docker configuration / setup:</description>
     </item>
 
     <item>

docs/setup/installation/index.html

@@ -23,7 +23,7 @@
 <meta itemprop="name" content="Installation">
 <meta itemprop="description" content="How to build and compile NCA">
 
-<meta itemprop="wordCount" content="665">
+<meta itemprop="wordCount" content="633">
 <meta itemprop="keywords" content="" /></head>
 <body>
   <div class="container"><div class="skip"><a href="#maincontent">Skip to main content</a></div>
@@ -285,14 +285,8 @@ <h2 id="preliminary-setup">Preliminary Setup</h2>
 <p>Manual installation has several prerequisites:</p>
 <ul>
 <li>Poppler Utils for PDF processing</li>
-<li>OpenJPEG 2 + command-line tools for JP2 generation
-<ul>
-<li>The command-line tools will probably need to be <strong>manually compiled</strong> to
-support converting PNG files. Most distributions of Linux don&rsquo;t have this
-by default, hence the need to manually compile.</li>
-</ul>
-</li>
-<li>A recent version of GhostScript - 10+ is recommended</li>
+<li>OpenJPEG 2 + command-line tools for JP2 generation</li>
+<li>GhostScript</li>
 <li>GraphicsMagick</li>
 <li>MariaDB</li>
 <li>A IIIF server capable of handling tiled JP2 files without a ton of overhead (e.g.,
@@ -320,10 +314,11 @@ <h2 id="compile">Compile</h2>
 as you compile on the same architecture your production system has (or change
 the <code>Makefile</code> to cross-compile for the targeted architecture).</li>
 <li><a href="https://github.com/mgechev/revive">revive</a>: <code>go install github.com/mgechev/revive@latest</code></li>
+<li><code>goimports</code> (replaces <code>gofmt</code>): <code>go install golang.org/x/tools/cmd/goimports@latest</code></li>
 </ul>
 <p>The easiest way to compile is simply running <code>make</code> in the source directory.
 This will grab various Go packages the application requires, validate the
-current code (via revive, gofmt, and go vet, for development purposes), and
+current code (via revive, goimports, and go vet, for development purposes), and
 build all the binaries.</p>
 <p>A full compilation from a clean repository should take about 15 seconds, though
 this can depend on network speed the first time dependencies are pulled from