Implement check command

[mtojek]

Fixes: #10

Note: some commands are placeholders, they will be implemented in another issues.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[exekias]

What's the point of adding a placeholder? Why not waiting for the implementation to have it exposed in the cmdline?

[mtojek]

The added value in this PR is the composition of multiple targets and the expected order. I suggest to look at this as a skeleton defining the development process.

It would be easier to test if we have a single command "check" for the integration, which will go through multiple goals. For example: if you implement a command "validate", all you have to do is to run "check" which will iterate over other targets (build, format, etc.) and verify if there are still correct.

This repository is private currently, so I hope it won't introduce much noise.

[mtojek]

Another pros -

Imagine we decide to integrate it with integrations: elastic-package check and no need to touch integrations later on and simply deliver next features of the elastic-package.

[exekias]

Thanks I understand this better now. I have a few concerns about this:

• including test as part of check. Wouldn't this make check too slow? This may be ok if that's what we are looking for
• In general I have the feeling that we are creating too many validation subcommands (validate, check, format). Would be nice to converge them to make this simpler

[mtojek]

We had an offline discussion, agreed on the following approach:

• check - aggregates multiple commands (format, lint, build)
• test - keep it aside
• validate becomes lint

[mtojek]

I think Github is facing an outage right now. Missing commits (already pushed) here: https://github.com/mtojek/elastic-package/commits/10-check-integration

[masci]

Sorry for hijacking this PR but I think we could make a more consistent use of the terms package and integration.

I understand that at this point in time integrations represent the only available type of package but this will hopefully change in the future.

So we should decide whether this tool is somehow dedicated to the development of specific packages of type: integration, and in this case I would change the name of the tool and maybe move the source code into the elastic/integrations repo; or we say this is a general purpose tool to support the development of packages, and in this case I'd consolidate the naming scheme around source code, docs, etc. avoiding to refer to integrations when the command can actually work with any package type.

[mtojek]

Hey @masci, thanks for looking into this! I believe we have a discussion about this in the past.

We decided to move on with packages, but as long as there are no other types even defined (or in plans), I sticked to integrations. I can try to get rid of words referring to "integrations" in as many places as possible, but internally there will be support only for integrations.

I prefer to keep this in a separate repository as the original plan is to keep integration source in the integrations repo and nothing else (no logic, tooling, side scripting).

I'd like to listen to other opinions on this. @exekias @ruflin @ycombinator

[exekias]

I'm +1 on having this tool as the reference for package development, where integrations will be only a subset of that. In that sense I would refrain from mentioning "integrations" here.

In that sense I think it also makes sense to have the tool in a different repo, not only because of this "generic" soul, but also because I expect that once things get stable, elastic-package users won't necessarily be go developers (with the go toolchain installed for instance). This project should have its own lifecycle.

[mtojek]

If you don't mind I would go over this in another PR. It's not directly in the scope of this PR.

[mtojek]

#35

[mtojek]

Resolving in favor of #34