Description

As of now we rely on the default linter configuration. Consider to introduce a linter config based on the config present in lifecycle-manager.

Reasons

Further increase the quality of the project.

Attachments

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-1
Explanation: Does README mention REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Description

Some of the services under internal/service may be specific to the scaffold command. Those should be put directly under internal/service/scaffold.

Consider that we are adding further commands (e.g., create) which may make use of generic services like the filegenerator.

Reasons

Keep the project structure clean.

Attachments

Description

For the new CLI, we want to create an abstraction layer shielding the OCM dependency. The abstraction shall provide an API focussing on the functionality we need and internally delegate to the OCM library.

Reasons

This will reduce our code's coupling to the OCM library and make it easier in the future to cope with (breaking) changes within the library.

Attachments

Description

Increase test coverage for validations in internal/service/scaffold/options.go. Some execution paths relying on static functions are untested, e.g., the evaluation of the directory or the regexes.

It must be evaluated what the best approach is. E.g., to make a service that is getting helper functions as explicit dependencies.

Reasons

Further increase the quality of the project.

Attachments

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-4
Explanation: Is it compliant with REUSE rules? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Description

Right now we have filegenerator and reuse-filegenerator which is a decorator on the former. The more idiomatic way in Go would be to move both into the same package and use functional options to configure reuse on top of the plain file generator.

It may look something like the following:

generator, err := filegenerator.New(
  kind,
  fileSystem,
  contentProvider,
  fileGenerator.WithReuse()
)

Figuring out the proper typing and structuring (e.g., with the decorator pattern) may be tricky.

Reasons

Further increase the quality of the project.

Attachments

Description

We need to create a release pipeline. The release pipeline should be triggered manually and:

• build the artifacts for the given version and store them in a proper location (prerequisite: #18)
• create a tag for the given version
• create a release for the given version
  • release to include release notes of what has changed since last release

Reasons
Being able to provide the tool to other teams.

Attachments

Descripton

Implement the service for creating modules. This should provide the same functionality as in CLI, but the implementation should be clean and follow high code quality standards.

To be determined

The new implementation should already consider the requirements for multiple control planes and shipping to restricted markets. I.e., the packaging and shipping via OCM.

Acceptance Criteria

• service for creating modules implemented
• service called from modulectl create module command
• service options are validated for correct input
• service (including sub-services) is covered with unit tests
• E2E tests introduced via #27 are green

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-assigned_teams-1
Explanation: Does it have enough teams on GitHub? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Description

Copy the "command layer" for the module creation from the Kyma CLI. Follow the example from the create scaffold command. The command should have a dependency to a module creation service interface it calls in the Run function. The concrete service will be implemented as part of another ticket (#28), but the necessary interface (options structure) should already be defined.

When defining the options, the existing options from the scaffold command should be considered. It may be split into reusable parts. It is enough to just create the struct with the necessary fields. The validations will also be covered in the other ticket.

Acceptance Criteria

• module command added to modulectl create command
• command is unit tested (i.e., command composition and flag to option parsing)

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-3
Explanation: Is it registered in REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Description

Add unit tests for the tools package which is untested so far.

Reasons

Further increase the quality of the project.

Attachments

Description

We need to create a prow build job. The configuration can be based on one of the existing jobs: https://github.com/kyma-project/test-infra/tree/main/prow/jobs/kyma-project. Once there, the job should also be linked from the Pipeline Check tab in the project.

We could use similar setup as the old Kyma CLI was using (without the Homebrew part), Neighbors can provide more info on the best location to store the build artifact

Reasons

Compliance with security requirements and being able to release modulectl at some point.

Attachments

Description

The functionality of creating a scaffolding for a new module should be imported from the CLI

Acceptance Criteria

• Implement Module Scaffolding functionality
• Don't copy the Kyma CLI code
  • Stick to Cobra framework
  • Adhere to principles presented here: kyma-project/cli#1908
• Covered with unit-tests

Description

The previous implementation included command steps. We need to consider adding steps again.

Reasons

Better feedback to the end user and more robustness for the e2e tests (rely on the step output and not plain logs).

Attachments

Description

The functionality of creating a new module should be imported from the CLI

Acceptance Criteria

• Implement Module Create functionality
• Don't copy the Kyma CLI code
  • Stick to the Cobra framework
  • Adhere to principles presented here: kyma-project/cli#1908
• Covered with unit-tests
• Ensure validations for module create command also cover module scaffolding command
  • when refactoring moduleConfig and making it a public type, update tests/e2e/create/scaffold/scaffold_test.go to use the public type instead the copied one.

Description

Copy the E2E test pipeline for the module creation from the Kyma CLI. Align the copied pipelines with the existing E2E test for scaffold creation and modify the code to call the new modulectl create module command instead of kyma alpha create module.

Note: it is expected that the tests will be failing. After successfully implementing the new command, all tests should become green (verification that the new implementation is correct).

Acceptance Criteria

• E2E test pipelines for module creation created
  • call the new modulectl create module command
  • fail because logic is not implemented yet

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-2
Explanation: Does it have LICENSES directory with licenses? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html