Install pebble via implicit part

[cjdcordeiro]

Since Pebble will be the entrypoint for all ROCKs, we must have it installed for all ROCKs too.

Similar to what Kerncraft is doing at https://github.com/canonical/kerncraft/pull/22/files#diff-a5aa2c8752af7f6a4943ee8761dd913a6a7662e7d5e7b4c80602e225070617d2, also in Rockcraft we must add a part for building and installing Pebble into the ROCK.

The difference between this PR and the Kerncraft implementation is that 1) the Pebble part is implicit (always there), and 2) there's no need for a custom Pebble plugin, since Pebble is just a Go application, so we can just use the already existing Go plugin from craft-cli.

• Have you signed the CLA?

---

[cjdcordeiro]

@sergiusens @cmatsuoka @tigarmo pls note the comment in https://github.com/canonical/rockcraft/pull/59/files#diff-0ea7d1a44d76c7792a852505490ca9e3fb738ec2a7814b051ebc828efb8ceceeR108 (it isn't a serious problem since we have unit tests which would flag an invalid part spec, but still, maybe there is a better place for this)

[cjdcordeiro]

the CI error could be an intermittent one. could you please re-run the workflow?

[cjdcordeiro]

I'm not sure what the error is about. I can't reproduce it locally. I've run spread and also directly rockcraft, and couldn't reproduce.

[tigarmo]

Weird, it failed again:

subprocess.CalledProcessError: Command '['snap', 'install', 'go', '--channel', '1.19/stable', '--classic']' returned non-zero exit status 1.

[tigarmo]

I think the other tests use an older version of go; maybe we should use latest/stable?

[cjdcordeiro]

oh but now the error was different. So the go installation failed due to lack of disk space

[tigarmo]

Very curious, these machines have 40G of storage I think. @sergiusens any insight into why this would fail?

[tigarmo]

Hi @cjdcordeiro, I updated the PR with a few changes:

• Merged main, fixed a bunch of conflicts (nothing of note there);
• Added two commits: one updating the pebble part because of issue Allow customization/removal of automatic "go generate" step #102, and one refactoring the code a bit to support a pre-existing, user-set pebble part. I also moved the code to a separate _add_pebble_data() function to have an place to look at when we do further pebble changes.

Please take a look at the changes, and if you +1 them I'll go ahead and approve/merge the PR. Thanks!

[cjdcordeiro]

Thanks @tigarmo ! Nice work.

It all lgtm except https://github.com/canonical/rockcraft/pull/59/files#diff-0ea7d1a44d76c7792a852505490ca9e3fb738ec2a7814b051ebc828efb8ceceeR493. This is not according to our spec, because it allows users to create a ROCK without Pebble as the entrypoint.

I understand that the objective is to align with #65, but we don't need to do this now. My fear is that we are introducing a capability which later on must be removed ("being able of not having pebble").

[tigarmo]

This is not according to our spec, because it allows users to create a ROCK without Pebble as the entrypoint.

How would the users create a ROCK without Pebble as the entrypoint? Do you mean if they have a part called pebble that actually has unrelated things?

[cjdcordeiro]

This is not according to our spec, because it allows users to create a ROCK without Pebble as the entrypoint.

How would the users create a ROCK without Pebble as the entrypoint? Do you mean if they have a part called pebble that actually has unrelated things?

exactly. something like

parts:
  pebble:
    plugin: nil

Which could be there either by mistake or by an ill-intended desire to avoid Pebble

[tigarmo]

I see. I updated the code to fail if a pebble part is already present, and we can revisit the customization support in the near future

[cjdcordeiro]

perfect