diff --git a/changes/187.changed b/changes/187.changed new file mode 100644 index 00000000..e3a6861a --- /dev/null +++ b/changes/187.changed @@ -0,0 +1,3 @@ +Adds dependabot.yml control file to only update direct packages. +Adds watchmedo to the celery dev container to watch Python files and restart the celery worker. +Updates the example in the dev_contributing about the change fragments. \ No newline at end of file diff --git a/changes/187.fixed b/changes/187.fixed new file mode 100644 index 00000000..70ff8fcc --- /dev/null +++ b/changes/187.fixed @@ -0,0 +1 @@ +Disables alert of WebEx token missing to only if WebEx is enabled. \ No newline at end of file diff --git a/dependabot.yml b/dependabot.yml new file mode 100644 index 00000000..114c0e03 --- /dev/null +++ b/dependabot.yml @@ -0,0 +1,12 @@ +--- +version: 2 +updates: + - package-ecosystem: "pip" + directory: "/" + allow: + - dependency-type: "direct" + versioning-strategy: "increase" + - package-ecosystem: "pip" + directory: "/" + ignore: + - dependency-type: "indirect" diff --git a/development/creds.example.env b/development/creds.example.env index 0c158d77..65ea4808 100644 --- a/development/creds.example.env +++ b/development/creds.example.env @@ -13,4 +13,5 @@ REDIS_PASSWORD=notverysecurepwd SECRET_KEY=r8OwDznj!!dci#P9ghmRfdu1Ysxm0AiPeDCQhKE+N_rClfWNj NAUTOBOT_CREATE_SUPERUSER=true NAUTOBOT_SUPERUSER_API_TOKEN=0123456789abcdef0123456789abcdef01234567 -NAUTOBOT_SUPERUSER_PASSWORD=admin \ No newline at end of file +NAUTOBOT_SUPERUSER_PASSWORD=admin +NAUTOBOT_LOG_LEVEL=DEBUG \ No newline at end of file diff --git a/development/docker-compose.base.yml b/development/docker-compose.base.yml index 24c46300..b596b1c3 100644 --- a/development/docker-compose.base.yml +++ b/development/docker-compose.base.yml @@ -21,6 +21,8 @@ services: depends_on: - "postgres" - "redis" + healthcheck: + disable: true <<: *nautobot-build <<: *nautobot-base worker: diff --git a/development/docker-compose.celery.yml b/development/docker-compose.celery.yml index 9797c49d..52341546 100644 --- a/development/docker-compose.celery.yml +++ b/development/docker-compose.celery.yml @@ -7,7 +7,10 @@ services: - "dev.env" - "creds.env" tty: true - entrypoint: "nautobot-server celery worker -l INFO" + entrypoint: + - "sh" + - "-c" # this is to evaluate the $NAUTOBOT_LOG_LEVEL from the env + - "watchmedo auto-restart --directory './' --pattern '*.py' --recursive -- nautobot-server celery worker -l $$NAUTOBOT_LOG_LEVEL --events" depends_on: - "nautobot" healthcheck: diff --git a/docs/dev/dev_contributing.md b/docs/dev/dev_contributing.md index 71ed35e9..58776ead 100644 --- a/docs/dev/dev_contributing.md +++ b/docs/dev/dev_contributing.md @@ -91,7 +91,7 @@ def get_rack(dispatcher, site_slug, rack_id): ### `return CommandStatusChoices.STATUS_SUCCEEDED` This indicates that the command was successful, and no further details are necessary in the logging. -You *could* return another status code besides `STATUS_SUCCEEDED` in this pattern, but in general any other status +You _could_ return another status code besides `STATUS_SUCCEEDED` in this pattern, but in general any other status code should be accompanied by an explanatory message: ### `return (CommandStatusChoices.STATUS_FAILED, details_str)` @@ -136,10 +136,10 @@ You shouldn't need to make any changes to the `workers` module in this scenario. be assigned to you so that others are aware it's being worked on. A maintainer will then mark the issue as "accepted." -- If you followed the project guidelines, have ample tests, code quality, you will first be acknowledged for your work. So, thank you in advance! After that, the PR will be quickly reviewed to ensure that it makes sense as a contribution to the project, and to gauge the work effort or issues with merging into *current*. If the effort required by the core team isn’t trivial, it’ll likely still be a few weeks before it gets thoroughly reviewed and merged, thus it won't be uncommon to move it to *near term* with a `near-term` label. It will just depend on the current backlog. +- If you followed the project guidelines, have ample tests, code quality, you will first be acknowledged for your work. So, thank you in advance! After that, the PR will be quickly reviewed to ensure that it makes sense as a contribution to the project, and to gauge the work effort or issues with merging into _current_. If the effort required by the core team isn’t trivial, it’ll likely still be a few weeks before it gets thoroughly reviewed and merged, thus it won't be uncommon to move it to _near term_ with a `near-term` label. It will just depend on the current backlog. - All code submissions should meet the following criteria (CI will enforce -these checks): + these checks): - Python syntax is valid - All unit tests pass successfully - PEP 8 compliance is enforced, with the exception that lines may be @@ -149,7 +149,7 @@ these checks): ### Creating Changelog Fragments -All pull requests to `next` or `develop` must include a changelog fragment file in the `./changes` directory. To create a fragment, use your github issue number and fragment type as the filename. For example, `2362.added`. Valid fragment types are `added`, `changed`, `deprecated`, `fixed`, `removed`, and `security`. The change summary is added to the file in plain text. Change summaries should be complete sentences, starting with a capital letter and ending with a period, and be in past tense. Each line of the change fragment will generate a single change entry in the release notes. Use multiple lines in the same file if your change needs to generate multiple release notes in the same category. If the change needs to create multiple entries in separate categories, create multiple files. +All pull requests to `next` or `develop` must include a changelog fragment file in the `./changes` directory. To create a fragment, use your github issue number and fragment type as the filename. For example, `2362.added`. Valid fragment types are `added`, `changed`, `deprecated`, `fixed`, `removed`, and `security`. The change summary is added to the file in plain text. Change summaries should be complete sentences, starting with a capital letter and ending with a period, and be in past tense. Each line of the change fragment will generate a single change entry in the release notes. Use multiple lines in the same file if your change needs to generate multiple release notes in the same category. If the change needs to create multiple entries in separate categories, create multiple files. In the example below 1234 is the _issue_ number. !!! example diff --git a/nautobot_chatops/api/views/webex.py b/nautobot_chatops/api/views/webex.py index 7e43645c..d1a41f01 100644 --- a/nautobot_chatops/api/views/webex.py +++ b/nautobot_chatops/api/views/webex.py @@ -42,10 +42,11 @@ API = WebexTeamsAPI(access_token=TOKEN) BOT_ID = API.people.me().id except (AccessTokenError, ApiError): - logger.warning( - "Missing or invalid WEBEX_TOKEN setting. " - "This may be ignored if you are not running Nautobot as a WebEx chatbot." - ) + if settings.PLUGINS_CONFIG["nautobot_chatops"].get("enable_webex"): + logger.warning( + "Missing or invalid WEBEX_TOKEN setting. " + "This may be ignored if you are not running Nautobot as a WebEx chatbot." + ) API = None BOT_ID = None diff --git a/pyproject.toml b/pyproject.toml index 81bc010a..3a95c4a9 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [tool.poetry] name = "nautobot-chatops" -version = "1.11.0" +version = "1.11.1" description = "A plugin providing chatbot capabilities for Nautobot" authors = ["Network to Code, LLC "] readme = "README.md"