redhat-developer / redhat-developer/rhdh-fullsend

Track repository-local Yarn wrapper in the RHDH Fullsend installation

Open
#29 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Dockerfile
Stars
2
Forks
7
Avg merge
1d 13h
Merged PRs (30d)
8

Description

Purpose

Keep an open tracking issue for the RHDH-specific Yarn customization introduced by rhdh-agentic#98:

.fullsend/rhdh/bin/yarn

This issue should remain open for as long as the repository-local wrapper or equivalent RHDH-specific modification is required.

Context

rhdh-fullsend#24 tracked the immediate Yarn/Corepack outage and was closed after PR #98 restored working Yarn commands. That incident is resolved, but its solution remains a local customization that needs ownership and eventual upstreaming or centralization.

The reference rhdh-agentic installation currently inherits ghcr.io/fullsend-ai/fullsend-code:latest and exposes the target repository's vendored Yarn release through a wrapper mounted as /sandbox/workspace/bin/yarn.

The source is namespaced under .fullsend/rhdh/ because Fullsend v0.30 overlays the standard .fullsend layered directories before resolving the harness.

Current modification

The wrapper directly executes:

${FULLSEND_TARGET_REPO_DIR}/.yarn/releases/yarn-4.12.0.cjs

This avoids:

  • corepack enable attempting to write shims into read-only /usr
  • downloading Yarn during every agent run
  • relying on a custom RHDH sandbox image solely to provide Yarn

The harness additionally delivers Yarn proxy configuration and an npm policy adjustment for encoded scoped-package paths.

Tracking concerns

  • The Yarn version is hardcoded and must be updated in lockstep with .yarnrc.yml and .yarn/releases/.
  • The wrapper assumes every target repository vendors Yarn at this exact layout.
  • The customization currently lives in rhdh-agentic, rather than being generated or owned centrally by rhdh-fullsend.
  • rhdh-fullsend documentation still describes the custom RHDH image and /usr/local/bin/yarn, while the reference installation uses the upstream image and /sandbox/workspace/bin/yarn.
  • Other RHDH repositories must reproduce this behavior to match the reference installation.

Desired outcome

Move this requirement to the most appropriate shared layer—Fullsend core/base image, the shared agents installation, or a centrally managed rhdh-fullsend blueprint—so enrolled repositories do not need a hand-maintained Yarn wrapper.

If upstreaming is not practical, centralize generation and version discovery so repositories do not hardcode a Yarn release filename.

Acceptance criteria

  • Decide the long-term owner and layer for Yarn provisioning in RHDH Fullsend agents.
  • Remove the hardcoded yarn-4.12.0.cjs coupling or validate/update it automatically from .yarnrc.yml.
  • Align rhdh-fullsend documentation with the reference rhdh-agentic installation.
  • Ensure the same solution can be promoted unchanged to other RHDH repositories.
  • Remove .fullsend/rhdh/bin/yarn from enrolled repositories, or explicitly document it as a supported centrally managed customization.
  • Keep this issue open while the RHDH-specific modification remains deployed.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading .fullsend/rhd/bin/yarn, .yarnrc.yml, .yarn/releases/, and the rdhh-fullsend documentation describing the custom image and /usr/local/bin/yarn. Compare those details with the reference rhdh-agentic installation and determine the appropriate shared owner. Done means the hardcoded wrapper is removed or centrally managed, documentation is aligned, and the solution can be promoted to other RHDH repositories.

Written by the indexing model from the issue text.

Assessment

Tech stack
dockerfile
Domain
build-system, devops, infrastructure
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.