← Back to issue list

allow user configuration of the Pebble entrypoint binary

View original Github issue

Metadata

Project
rockcraft
Number
#65
Type
issue
State
open
Author
cjdcordeiro
Labels
—
Created
Updated
Closed
—

Current evaluation

Pebble is still staged from the hard-coded pebble/latest/stable snap; user-selectable channels or revisions and policy for custom versus generated Pebble layers remain unimplemented.

Suggested action: keep open

Reason: The 2026 triage comment explicitly concludes that the request remains valid, and current code still hard-codes pebble/latest/stable while rejecting changes to the default Pebble part. Implementation remains open, but it needs design decisions for channel versus revision selection and whether custom layers are supported, validated, or rejected.

Evaluated by: mr-cal-bot

Impact: 55 Quick Win: 13 Complexity: 63 Confidence: 96 Actionability: 64

Issue body

Users can define the Pebble services to be executed, but they should also be able to configure certain parameters about the Pebble software which is being installed in the ROCK. The most obvious parameter is the Pebble version, i.e., users should be able to have a say on the version of Pebble that is being used as the ROCK entrypoint. See https://github.com/canonical/rockcraft/pull/59#discussion_r954192413 for more details --- edit: Additionally, Rockcraft should know how to handle (check/support/deny) the user definitions of custom Pebble layers. Example: the user defines the PEBBLE_LAYERS_PATH and inner layer files within a custom part, conflicting with the rockcraft-defined base Pebble layer from the `services` field (see related discussion in https://github.com/canonical/rockcraft/pull/205#discussion_r1154090694)

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 55
Quick Win: 13
Complexity: 63
Confidence: 96
Actionability: 64
keep open Pebble is still staged from the hard-coded pebble/latest/stable snap; user-selectable channels or revisions and policy for custom versus generated Pebble layers remain unimplemented.
qwen/qwen3.6-35b-a3b
Impact: 50
Quick Win: 19
Complexity: 50
Confidence: 70
Actionability: 75
needs triage Feature request to allow users to configure Pebble snap channel/version and define custom Pebble layers in rockcraft.yaml. Currently hardcoded to pebble/latest/stable with no user layer conflict policy.
qwen/qwen3.8-27b
Impact: 45
Quick Win: 18
Staleness: 50
Complexity: 60
Confidence: 85
Support Request: 10
keep open Feature request to let users configure the Pebble entrypoint snap channel/version and set a policy for user-supplied Pebble layers. Triaged 2026-02-26 as still valid; channel still hardcoded to pebble/latest/stable, no PR proposed.
qwen/qwen3.6-35b-a3b
Staleness: 50
Complexity: 65
Confidence: 85
Support Request: 10
keep open Request to allow configurable Pebble version/channel and define policies for user-supplied Pebble layers in Rockcraft. Recently triaged and confirmed valid, but no implementation or PR exists yet.
qwen3.6-35b-a3b-mtp-q6
Staleness: 45
Complexity: 65
Confidence: 85
Support Request: 10
needs triage Feature request to allow configurable Pebble version and layer handling in Rockcraft. Currently hardcoded to latest/stable. Validated as still relevant, but lacks implementation or official prioritization.

Update history

No update history recorded yet.

Related work

  • Related To: canonical/rockcraft#205 (confidence 100%)

    This merged PR introduced the Pebble entrypoint and generated services/checks layer; the issue explicitly cites its discussion about custom-layer collisions.

  • Related To: canonical/rockcraft#59 (confidence 98%)

    The original request explicitly cites this PR discussion as the source of the Pebble user-configuration requirement.

Related issues

No related issues found above the similarity threshold.