We received some feedback from BuildersHub and one of them requested parameters within the yaml scope for specific situations, as described below:
Feedback Builder Hub:
It would be interesting to have within the yaml scope of a plugin parameters that would be validated by the CLI, for example:
1 - applicable in a project without a stack or not, for example: the developer is developing a java stack apply plugin within a project he already has, but was not built by a stackspot command (starter or another apply plugin). Today the cli even asks if the user really wants to apply the plugin, if it is not a project generated by stackspot. But we recommend having a declarative configuration in the plugin, in case it is not useful to apply in a stackspot project or the client is unable to apply the plugin.
2 - the plugin can be applied multiple times.
3 - is there a plugin that needs to have been applied previously.
Descrição
Recebemos alguns feedbacks da BuildersHub e um deles solicitava parâmetros dentro do escopo do yaml para situações específicas, conforme descrito abaixo:
Feedback BuildersHub
Seria interessante ter dentro do escopo do yaml de um plugin parâmetros para o mesmo que seriam validados pela CLI, por exemplo:
1 - aplicável em um projeto sem stack ou não, por exemplo: desenvolvedor está realizando um apply plugin da stack java dentro de um projeto que ele já possui, mas não foi construído por um comando da stackspot (starter ou outro apply plugin). Hoje o cli até pergunta se o usuário quer mesmo aplicar o plugin, caso não seja um projeto gerado pela stackspot. Mas gostaríamos de ter uma configuração declarativa no plugin, que caso ele não esteja aplicando em um projeto stackspot o cliente não consiga aplicar o plugin.
2 - plugin pode ser aplicado múltiplas vezes.
3 - se existe algum plugin que precisa ter sido aplicado anteriormente.
Solução
1 - Capacidade de determinar os plugins que só podem ser utilizados em projetos já criados pela Stackspot, não permitindo converter projetos existentes em projetos StackSpot.
2 - Capacidade de determinar que um plugin é de uso único em uma aplicação ou em uma infra. Será validado se alguma vez ele já foi aplicado, independente da versão, e caso positivo, então não será possível aplicá-lo, caso possua essa flag em seu manifesto. Não será levado em consideração versão do plugin.
3 - Capacidade de determinar plugins que são requeridos para um determinado plugin, caso os plugins requeridos não estejam aplicados ainda, o CLI irá informar que eles são necessários, e o usuário deverá aplicá-los manualmente antes de prosseguir. Não será levado em consideração versão do plugin.
Exemplo da estrutura do yaml com a solução
Obs: Os campos novos estão dentro do destaque vermelho e em negrito. Estamos abrangendo plugins do tipo app e infra.
Description
We received some feedback from BuildersHub and one of them requested parameters within the yaml scope for specific situations, as described below:
Feedback Builder Hub:
It would be interesting to have within the yaml scope of a plugin parameters that would be validated by the CLI, for example:
1 - applicable in a project without a stack or not, for example: the developer is developing a java stack apply plugin within a project he already has, but was not built by a stackspot command (starter or another apply plugin). Today the cli even asks if the user really wants to apply the plugin, if it is not a project generated by stackspot. But we recommend having a declarative configuration in the plugin, in case it is not useful to apply in a stackspot project or the client is unable to apply the plugin. 2 - the plugin can be applied multiple times. 3 - is there a plugin that needs to have been applied previously.
Descrição
Recebemos alguns feedbacks da BuildersHub e um deles solicitava parâmetros dentro do escopo do yaml para situações específicas, conforme descrito abaixo:
Feedback BuildersHub
Seria interessante ter dentro do escopo do yaml de um plugin parâmetros para o mesmo que seriam validados pela CLI, por exemplo: 1 - aplicável em um projeto sem stack ou não, por exemplo: desenvolvedor está realizando um apply plugin da stack java dentro de um projeto que ele já possui, mas não foi construído por um comando da stackspot (starter ou outro apply plugin). Hoje o cli até pergunta se o usuário quer mesmo aplicar o plugin, caso não seja um projeto gerado pela stackspot. Mas gostaríamos de ter uma configuração declarativa no plugin, que caso ele não esteja aplicando em um projeto stackspot o cliente não consiga aplicar o plugin. 2 - plugin pode ser aplicado múltiplas vezes. 3 - se existe algum plugin que precisa ter sido aplicado anteriormente.
Solução
1 - Capacidade de determinar os plugins que só podem ser utilizados em projetos já criados pela Stackspot, não permitindo converter projetos existentes em projetos StackSpot. 2 - Capacidade de determinar que um plugin é de uso único em uma aplicação ou em uma infra. Será validado se alguma vez ele já foi aplicado, independente da versão, e caso positivo, então não será possível aplicá-lo, caso possua essa flag em seu manifesto. Não será levado em consideração versão do plugin. 3 - Capacidade de determinar plugins que são requeridos para um determinado plugin, caso os plugins requeridos não estejam aplicados ainda, o CLI irá informar que eles são necessários, e o usuário deverá aplicá-los manualmente antes de prosseguir. Não será levado em consideração versão do plugin.
Exemplo da estrutura do yaml com a solução
Obs: Os campos novos estão dentro do destaque vermelho e em negrito. Estamos abrangendo plugins do tipo app e infra.
Artefatos
Domínios/ Canais impactados
Definition Of Done