Skip to content

[Proposal] _dev folder #22

@ycombinator

Description

@ycombinator

We are starting to implement test runners for various types of package tests in the elastic-package tool: elastic/elastic-package#15, elastic/elastic-package#16, etc. This is bringing up the need to keep files that are needed only at development time somewhere under the package root folder. Examples of such files could be test golden files, docker compose files, etc. As such files would be needed at package development time only, we would not want them to be bundled into the package when it is published to the package registry.

So I'm proposing one change to the package spec and one change to the spec format itself:

  • Enhancing the package spec to allow for a new _dev folder that could exist under the package root folder or under a dataset's folder, so essentially:

    <packageRootFolder>/
      _dev/
      dataset/
        <dataset>/
          _dev/
    

    Conceptually, _dev is similar to the _meta folders we see in Beats. However, I went with _dev to make it more explicit that the files under this folder are intended for development-time only. That said, I'm not married to the name _dev; happy to consider other names or other ideas that achieve the goal of creating a space for development-time-only files.

  • Adding an optional field in the package spec format called visibility. This field is applicable to file or folder elements in the specification format. It can have values such as private or public, defaulting to public. It indicates whether the file or folder being defined in the spec should exist in the public version of the package, i.e. the one available from the package registry (visibility: public) or not (visibility: private).

    Accordingly, the aforementioned _dev folder specification would be set to visibility: private in the spec.

Metadata

Metadata

Assignees

Labels

discussIssue needs discussion

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions