Plugins API for external plugins should provide option to allow check what is the layout and plugins used in a chain

[camilamacedo86]

What broke? What's expected?

Example scenario:

The problem is that the declarative plugin needs to know if the project is being scaffolded with go/v4 or go/v3 so that it can perform correct scaffolding around Dockerfile in the init subcommand. and unfortunately, when the init subcommand is running, the PROJECT file won't exist at that point so extracting the layout from it won't be an option, which leads me to think that we need to either "inject" the config (the way we do with internal plugins) through the PluginRequest input.

Reproducing this issue

• Implement an external plugin
• Call it with kubuilder init plugins=myexternal/v1
• Then, we would need to ensure that from the code implementation of myexternal/v1 init sub-command would be possible to have access to Project Config (v3 only), which is used to track the project info and scaffold the PROJECT file.

An alternative solution would be to ensure that we generate the PROJECT file before we call the second plugin in a chain so that would allow the external plugins read the file and parse its information.

KubeBuilder (CLI) Version

3.10.0

PROJECT version

No response

Plugin versions

No response

Other versions

No response

Extra Labels

No response

[camilamacedo86]

Requester (who got this limitation): @em-r

@rashmigottipati @everettraven I think that would be a great fit for the GSC0 2023 program, either.
@Eileen-Yu would be great if we could fix this one it seems essential in the medium and long term for the external plugins be succeed.

[camilamacedo86]

HI @Eileen-Yu,

Could you please rebase the PR: #3526?

Also, could you please let us know if has any reason for we do not move with this one? Is that in a final state, could we get this one merged? WDYT?

Thank you a lot for your collaboration.

[Eileen-Yu]

Hi @camilamacedo86

I've rebased the PR.
The current PR pass the config as a string, which has been verified can be successfully received and written to the PROJECT file. So, I think this PR can be a simple version.
(In other words, if passing string is acceptable, I'd assume this pr is ready to review and merge.)

[Eileen-Yu]

Hi @camilamacedo86

I've rebased the PR. The current PR pass the config as a string, which has been verified can be successfully received and written to the PROJECT file. So, I think this PR can be a simple version. (In other words, if passing string is acceptable, I'd assume this pr is ready to review and merge.)

Based on some previous discussion, passing the config using the Cfg struct is proposed.
Basically, the cfg struct can be successfully updated via the debug logging:

{
  "version": "3",
  "projectName": "test",
  "layout": [
    "sampleexternalplugin/v1"
  ],
  "plugins": {...}
}

However, one issue happened from my side is: the PROJECT failed to get updated (though the cfg already been successfully overwritten):

{
  "version": "3",
  "layout": [
    "sampleexternalplugin/v1"
  ]
}

So, I think we can also try solving this in another PR OR I'm OK to continue on this one. How would you like?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[camilamacedo86]

/remove-lifecycle stale