Align package storage directories with public dir structure #376
Conversation
magefile.go
Outdated
| @@ -32,7 +32,7 @@ var ( | |||
|
|
|||
| publicDir = "./public" | |||
| buildDir = "./build" | |||
| packagePaths = []string{"./dev/packages/alpha/", "./dev/packages/beats/", "./dev/packages/example/"} | |||
| packagePaths = []string{"./dev/packages/alpha/"} | |||
There was a problem hiding this comment.
This will be reverted if we decided to move forward here.
|
@mtojek Would like to get your feedback on this change. If we move forward with this, I would also adjust the Beats generator and all built packages as part of this PR. |
Agree, we should ensure single place in which we store revision. I would consider removing it from internals of a package.
Hmm.. not sure about this part. It looks like the goal of storage would be only for storing artifacts ready to serve. Is it possible to generate them in flight? |
|
Undecided if we need to discuss how a package is released first before moving forward with this or @mtojek independent on this, the proposed directory change looks ok to you? |
Yup, it looks good to me. Could you please adjust also the import-beats script? I believe the only change should be in this line: packagePath := filepath.Join(outputDir, packageName+"-"+manifest.Version) |
ruflin
force-pushed
the
modify-package-path
branch
from
041def0 to
ade59e5
Compare
| @@ -32,7 +32,7 @@ var ( | |||
|
|
|||
| publicDir = "./public" | |||
| buildDir = "./build" | |||
| packagePaths = []string{"./dev/packages/alpha/", "./dev/packages/beats/", "./dev/packages/example/"} | |||
| packagePaths = []string{"./dev/packages/alpha/", "./dev/packages/example/"} | |||
There was a problem hiding this comment.
@mtojek As I would prefer to only have "rename" changes in this PR and not all other changes related to what change in Beats, I would prefer to get this PR in with beats excluded and how a follow up PR for it?
The package structure of the published packages is {package}/{version}. So far the stored packages had the structure {package}-{version}. This PR brings the two in line.
The driver behind the current data structure was to don't have too much nesting during development. But in the future, this structure is not meant for development but for storing packages. All released packages will be stored in our [package storage](https://github.com/elastic/package-storage). The package development will be moved to https://github.com/elastic/integrations. In there, I expect that only a directory {package} will exist without a version attached to it as in most cases only 1 version is developed in parallel. Then when the package should be released, it is copied to the storage to be deployed. Having the storage as close to the packages published should simplify the mental model.
ruflin
force-pushed
the
modify-package-path
branch
from
ade59e5 to
a50fdac
Compare
|
@mtojek @kaiyan-sheng @alakahakai @skh I merged this PR which probably means your PR needs a rebased. All that changes is the name of the directory so I hope it should be pretty straigh forward. Otherwise please ping me. |
The package structure of the published packages is {package}/{version}. So far the stored packages had the structure {package}-{version}. This PR brings the two in line.
The driver behind the current data structure was to don't have too much nesting during development. But in the future, this structure is not meant for development but for storing packages. All released packages will be stored in our package storage. The package development will be moved to https://github.com/elastic/integrations. In there, I expect that only a directory {package} will exist without a version attached to it as in most cases only 1 version is developed in parallel. Then when the package should be released, it is copied to the storage to be deployed. Having the storage as close to the packages published should simplify the mental model.