Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add command to create new integrations #2037

Merged
merged 10 commits into from
Aug 20, 2018
Merged

Add command to create new integrations #2037

merged 10 commits into from
Aug 20, 2018

Conversation

ofek
Copy link
Contributor

@ofek ofek commented Aug 13, 2018

Additional Notes

In a subsequent PR we will add different types of integrations too.

capture


from .utils import File

TEMPLATE_IN = """\
Copy link
Contributor

@gmmeyer gmmeyer Aug 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we put this (and the others) in separate files and read it in? I think it'll be easier to upkeep than as a string

@jeremy-lq
Copy link
Member

@phrawzty, let's make sure this is included in the updated developer docs.

[testenv]
platform = linux|darwin|win32
deps =
../datadog_checks_base
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-e

],

# The package we're going to ship
packages=['datadog_checks.{check_name}'],
Copy link
Contributor

@gzussa gzussa Aug 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'datadog_checks', 'datadog_checks.{check_name}' ?

@gzussa gzussa self-requested a review August 13, 2018 08:54
Copy link
Contributor

@gzussa gzussa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great 😃 and it will greatly help everyone 💯 but it needs to be updated. Here are my 3 main points:

  • First, I totally support @gmmeyer on using templates in separate files.
  • Also, some of these templates are not up to date (see inline comments).
  • Finally, we need a test that would generate a dummy check using this create a function and makes sure that the CI passes. It would be pretty bad if the generator didn't generate a valid skeleton.


TEMPLATE_JSON = """\
{{
"display_name": "{check_name_cap}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This template is not accurate. See doc. Some of these fields do not exist anymore

@zippolyte
Copy link
Contributor

Question: why not make a call to cookiecutter and apply the template we have in https://github.com/DataDog/cookiecutter-datadog-check ?

@phrawzty
Copy link
Contributor

call to cookiecutter and apply the template

This is currently (i.e. in our docs) the recommended way of generating the base files.

@ofek
Copy link
Contributor Author

ofek commented Aug 14, 2018

@zippolyte The main reason is we need a way to create different types of integrations e.g. tile-only, etc. and cookiecutter can’t do conditionals.

@phrawzty
Copy link
Contributor

need a way to create different types of integrations

More than one cookiecutter template?

@ofek
Copy link
Contributor Author

ofek commented Aug 14, 2018

@phrawzty Yes exactly!

@zippolyte
Copy link
Contributor

Yeah in that case we could have more than one cookiecutter template and do the conditionals in the dev package to choose the right one.
The issue I see with having the actual templates in the dev package is that it will make it more difficult to maintain the templates since you'd have to release the dev package when you make a change to them.

@ofek
Copy link
Contributor Author

ofek commented Aug 14, 2018

I think that's a fair tradeoff for having everything in one place. After all, a release is just one command.

Also, cookiecutter can't do dynamic things we need like normalizing package/check class names, creating a new GUID for the manifest, etc.

Copy link
Contributor

@zippolyte zippolyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, just one minor comment.

@click.pass_context
def create(ctx, name, integration_type, location, quiet, dry_run):
"""Create a new integration."""
integration_name = normalize_package_name(name)
Copy link
Contributor

@zippolyte zippolyte Aug 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should also keep a reference to name as is, and use it as the display name in README and so on, instead of check_name_cap

@@ -0,0 +1,47 @@
# Agent Check: {check_name_cap}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a line break between these headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!


[Run the Agent's `status` subcommand][5] and look for `{check_name}` under the Checks section.

## Data Collected
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line break please :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

## Data Collected
### Metrics

The {check_name_cap} check does not include any metrics at this time.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to say "at this time" here. The documentation represents now, not a hypothetical future.

The {check_name_cap} check does not include any metrics.

Imho, we could even shorten this to:

{check_name_cap} does not include any metrics.


### Service Checks

The {check_name_cap} check does not include any service checks at this time.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.


### Events

The {check_name_cap} check does not include any events at this time.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.


Need help? Contact [Datadog Support][6].

[1]: link to integration's site
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a templatable item as well? If that's problematic, we should surface this more obviously, like** LINK_TO_INTEGERATION_SITE ** or something 😄

@@ -0,0 +1,23 @@
{{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking - is the double-nesting here correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, since we use curly braces for template variables, we need to escape the actual curly braces by doubling them

$ ddev create -h
Usage: ddev create [OPTIONS] NAME

Create a new integration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't actually create a new Integration - it sets up the framework for a new Integration. We should be clear about that here and in the Options: below.


### Installation

The {check_name_cap} check is included in the [Datadog Agent][2] package, so you don't
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true of core Integrations, but not of extras; suggest hedging our default language here.

@@ -0,0 +1,3 @@
# (C) Datadog, Inc. {year}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless they're datadog employees we dont want to be forcing them to be signing over copyright to Datadog. In extras this could cause issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeremy-lq what should we do here? while this is useful for dd employees, it's not necessarily something we want to do for other authors in Extras.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to move the license and copyright notice to a conditional based on repo_choice.

author_email='{email_packages}',

# License
license='BSD',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's change this to the SPDX identifier: BSD-3-Clause

phrawzty
phrawzty previously approved these changes Aug 20, 2018
@zippolyte
Copy link
Contributor

What about my comment on using the original name parameter (before calling normalize_integration_name) as a display name (in README, CHANGELOG and manifest.json) ? Don't you think it would be better than using check_name_cap ?

@ofek
Copy link
Contributor Author

ofek commented Aug 20, 2018

Copy link
Contributor

@zippolyte zippolyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the changes ❤️

@ofek ofek merged commit a7d41ac into master Aug 20, 2018
@ofek ofek deleted the ofek/create branch August 20, 2018 21:42
nmuesch pushed a commit that referenced this pull request Nov 1, 2018
* Add command to create new integrations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants