-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
|
||
from .utils import File | ||
|
||
TEMPLATE_IN = """\ |
There was a problem hiding this comment.
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
@phrawzty, let's make sure this is included in the updated developer docs. |
[testenv] | ||
platform = linux|darwin|win32 | ||
deps = | ||
../datadog_checks_base |
There was a problem hiding this comment.
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}'], |
There was a problem hiding this comment.
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}'
?
There was a problem hiding this 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}", |
There was a problem hiding this comment.
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
Question: why not make a call to cookiecutter and apply the template we have in https://github.com/DataDog/cookiecutter-datadog-check ? |
This is currently (i.e. in our docs) the recommended way of generating the base files. |
@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. |
More than one cookiecutter template? |
@phrawzty Yes exactly! |
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. |
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. |
There was a problem hiding this 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) |
There was a problem hiding this comment.
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} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line break please :)
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 @@ | |||
{{ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
datadog_checks_dev/README.md
Outdated
$ ddev create -h | ||
Usage: ddev create [OPTIONS] NAME | ||
|
||
Create a new integration. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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
What about my comment on using the original |
There was a problem hiding this 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 ❤️
* Add command to create new integrations
Additional Notes
In a subsequent PR we will add different types of integrations too.