Integrate pre-commit
Makes my life easier wrt testing. Signed-off-by: Stephen Finucane <stephenfin@redhat.com> Change-Id: I5a79494eb81622be5e56686a1995eb2f0bddb085
This commit is contained in:
parent
d07d22e26b
commit
25f1cc2e25
29
.pre-commit-config.yaml
Normal file
29
.pre-commit-config.yaml
Normal file
@ -0,0 +1,29 @@
|
||||
---
|
||||
default_language_version:
|
||||
# force all unspecified python hooks to run python3
|
||||
python: python3
|
||||
repos:
|
||||
- repo: https://github.com/pre-commit/pre-commit-hooks
|
||||
rev: v4.4.0
|
||||
hooks:
|
||||
- id: trailing-whitespace
|
||||
- id: mixed-line-ending
|
||||
args: ['--fix', 'lf']
|
||||
exclude: '.*\.(svg)$'
|
||||
- id: check-byte-order-marker
|
||||
- id: check-executables-have-shebangs
|
||||
- id: check-merge-conflict
|
||||
- id: debug-statements
|
||||
- id: check-yaml
|
||||
files: .*\.(yaml|yml)$
|
||||
exclude: 'rally-scenarios/heat-fakevirt.yaml'
|
||||
- repo: local
|
||||
hooks:
|
||||
- id: flake8
|
||||
name: flake8
|
||||
additional_dependencies:
|
||||
- hacking>=3.1.0,<3.2.0
|
||||
language: python
|
||||
entry: flake8
|
||||
files: '^.*\.py$'
|
||||
exclude: '^(doc|releasenotes|tools)/.*$'
|
@ -169,7 +169,7 @@ Shows details for an event.
|
||||
|
||||
.. rest_status_code:: success status.yaml
|
||||
|
||||
- 200
|
||||
- 200
|
||||
|
||||
.. rest_status_code:: error status.yaml
|
||||
|
||||
|
@ -11,7 +11,7 @@ Show orchestration engine status
|
||||
|
||||
Enables administrative users to view details for all orchestration engines.
|
||||
|
||||
Orchestration engine details include engine id, binary, topic name, host,
|
||||
Orchestration engine details include engine id, binary, topic name, host,
|
||||
report interval, last updated time, health status, and host name.
|
||||
|
||||
Response Codes
|
||||
|
@ -5,16 +5,16 @@ repository_id=heat
|
||||
|
||||
# The name of the database table used to track the schema version.
|
||||
# This name shouldn't already be used by your project.
|
||||
# If this is changed once a database is under version control, you'll need to
|
||||
# change the table name in each database too.
|
||||
# If this is changed once a database is under version control, you'll need to
|
||||
# change the table name in each database too.
|
||||
version_table=migrate_version
|
||||
|
||||
# When committing a change script, Migrate will attempt to generate the
|
||||
# When committing a change script, Migrate will attempt to generate the
|
||||
# sql for all supported databases; normally, if one of them fails - probably
|
||||
# because you don't have that database installed - it is ignored and the
|
||||
# commit continues, perhaps ending successfully.
|
||||
# Databases in this list MUST compile successfully during a commit, or the
|
||||
# entire commit will fail. List the databases your application will actually
|
||||
# because you don't have that database installed - it is ignored and the
|
||||
# commit continues, perhaps ending successfully.
|
||||
# Databases in this list MUST compile successfully during a commit, or the
|
||||
# entire commit will fail. List the databases your application will actually
|
||||
# be using to ensure your updates to that database work properly.
|
||||
# This must be a list; example: ['postgres','sqlite']
|
||||
required_dbs=[]
|
||||
|
@ -0,0 +1 @@
|
||||
#!/bin/bash
|
@ -0,0 +1 @@
|
||||
#!/bin/bash
|
@ -5,7 +5,7 @@ features:
|
||||
for default roles and system scope. This is part of a broader community
|
||||
effort to support read-only roles and implement secure, consistent default
|
||||
policies.
|
||||
|
||||
|
||||
Refer to `the Keystone documentation`__ for more information on the reason
|
||||
for these changes.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user