Skip to content

bring the project into compliance with rust-template#2

Open
LoganBarnett wants to merge 2 commits into
mainfrom
template-compliance
Open

bring the project into compliance with rust-template#2
LoganBarnett wants to merge 2 commits into
mainfrom
template-compliance

Conversation

@LoganBarnett

Copy link
Copy Markdown
Owner

This is a diff-based compliance sync against rust-template, advancing the
recorded sync point from the April baseline to the template's current release.
Compliance is infrastructure alignment only; the project's Jenkins domain logic
is left untouched.

The bulk of the change adopts the template's shared foundation library, so
configuration resolution, logging, and the CLI entry point now flow from that
crate and pick up future improvements through a dependency bump rather than
hand-carried edits. Alongside it come the template's reusable CI, publish,
release-binary, branch-protection, and dependabot workflows; cross-compiled
macOS and Windows package outputs with their smoke checks; a dedicated CI dev
shell; the workspace clippy-lint enforcement of the no-panic and
combinator-preference conventions; the contribution and code-authoring docs; and
the review-gate harness.

Two changes are visible to users and are recorded in the changelog: the
environment variables that select the log level, log format, and config path are
now application-prefixed, and CLI logs are written to stderr only, dropping the
previous journald routing on Unix.

🤖 Generated with Claude Code

@LoganBarnett
LoganBarnett force-pushed the template-compliance branch 2 times, most recently from f190f25 to 4a14d35 Compare July 21, 2026 05:35
This is a diff-based compliance sync against rust-template, advancing the
recorded sync point from the April baseline to the template's current release.
Compliance is infrastructure alignment only; the project's Jenkins domain logic
is left untouched.

The bulk of the change adopts the template's shared foundation library, so
configuration resolution, logging, and the CLI entry point now flow from that
crate and pick up future improvements through a dependency bump rather than
hand-carried edits.  Alongside it come the template's reusable CI, publish,
release-binary, branch-protection, and dependabot workflows; cross-compiled
macOS and Windows package outputs with their smoke checks; a dedicated CI dev
shell; the workspace clippy-lint enforcement of the no-panic and
combinator-preference conventions; the contribution and code-authoring docs; and
the review-gate harness.

Two changes are visible to users and are recorded in the changelog: the
environment variables that select the log level, log format, and config path are
now application-prefixed, and CLI logs are written to stderr only, dropping the
previous journald routing on Unix.  Both fall out of adopting the foundation
entry point, and are why this lands as a breaking change.

Foundation is consumed as a git dependency; the Cargo and Nix lockfiles pin it
to the same template revision this sync targets.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
@LoganBarnett
LoganBarnett force-pushed the template-compliance branch 2 times, most recently from dee79a5 to 39e5dfe Compare July 22, 2026 04:38
jj's integration workflow had rotted: it installed Nix through a shut-down
action, and once that was replaced the harness surfaced a cascade of drift
against the current Jenkins and jj's own CLI restructure.

This brings the harness back to passing.  Jenkins is launched from its WAR,
since the packaged Jenkins provides no launcher command; its core is pinned to
the stable long-term line the bundled plugin set requires and the plugins are
regenerated to match; a configuration attribute newer Jenkins removed is
dropped; and the test runner now waits on an authenticated endpoint and threads
a single session so CSRF-crumb token minting succeeds.  The tests themselves are
repointed from jj's old flat command form to the current noun-verb subcommands.

The runner also hydrates each Pipeline job with one build before the suite runs:
a pipeline's parameters block only registers the job's parameter definitions
after its first build, so without this the first real build silently drops the
values the tests pass.

A separate defect is left for a follow-up change: jj still cannot enqueue a job
that declares no build parameters at all, which a dedicated non-parameterized
test will cover.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
@LoganBarnett
LoganBarnett force-pushed the template-compliance branch from 39e5dfe to cf46406 Compare July 22, 2026 04:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant