This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I413fea5768aec05e892d7977abadc279a06e1dcc
We officially support python35 now, so add py35
to the default envlist.
Also, just clean up the default list by removing
py33, py34, and pypy. I used to test by hand on py34
a long time ago, but I don't see much risk in breaking
this with python35 gating jobs.
I don't know of anyone attempting to run this on pypy
and I don't know if anyone has ever tested it either.
Change-Id: Ic9a98b2e126c9366cd325d8f47860d556bbb69ee
The openstack directory was used to keep codes from oslo-incubator,
we have retired oslo-incubator,so don't use this directory any more.
Change-Id: Id131b7147839cb5961454fad4837ea6385592304
The directory openstack/common was used to keep codes from oslo-incubator,
we have retired oslo-incubator,so don't use this directory any more.
Change-Id: I811306b0068e8adecf63995c9d47d6cb4b11a3c6
Releasenote translation publishing is being prepared. 'locale_dirs'
needs to be defined in conf.py to generate translated version of the
release notes.
Note that this repository might not get translated release notes - or
no translations at all - but we add the entry here nevertheless to
prepare for it.
Change-Id: I512878af85887d8cb7e8b241797ff611a35972c1
Remove E005 errors for hidden configuration files that do not
end with .sh, e.g., .profile, .bashrc, .bash_profile, etc.
Change-Id: I57d5b556cbc8843b744d3276a1dfdd7467d74fde
Closes-Bug: #1554653
Add note that we've fixed up python3 from here on out. CI testing
with I76d298ee8a1eb36358f1a9b49c0edfd73ade02a2
Change-Id: I0ac4c5b2c5bdacaaa0926041d11456472ffc08b6
We don't do the releasenotes as part of the doc build because it makes
things hard for packagers. This is the standard way to do it now and
we can setup jobs to publish them.
Change-Id: I6384f53a7604a5adc5d7282f2ae33945df1c88d0
As described in the python docs, use "universal_newlines" to
subprocess so the output are text streams.
With this, tox -e py34 works
Change-Id: I79091ed98054f25414d99824ee686bdf38ab968e
Since bashate has code which compiles multiple physical lines with
continuation backslashes into single logical lines, and then runs checks
on those, there is a (small) danger of future code changes causing the
E006 check to be incorrectly applied to long logical lines instead of
the shorter physical lines. Currently it all works fine, but there
could be a regression, so add a new test prevents that regression, by
explicitly requiring E006 to allow >=80 character logical lines which
are comprised of <80 character physical lines.
Signed-off-by: Adam Spiers <aspiers@suse.com>
Change-Id: I3d6ffca64b21f86921f13e06d24c8b942c16d4c4
Since we don't use the fileinput loop since
I781c1b642eb15fc7e2914791d5b77e8a4752db79, we can just check the last
line of the file before we start reading the next file (using the
bulitin fileinput loop tells you when a new file starts, but doesn't
tell you went a file ends, hence this work-around).
Which is actually the correct thing to do, because as it is, you can't
detect the lack-of-newline unless you're checking two files. This
removes a bunch of prev_* variables that aren't needed. This is also
I think why we never had a test-case. So fix that too.
Change-Id: I54963cd25efc9f9603fbcc60b8e25bb11ea2d7db
As described in comments, ((expr)) has a trap that if expr is 0, the
return value is 1. This will trigger a failure with "set -e" and can
be very confusing. It is good defensive programming to avoid this
with explicit assignment.
Change-Id: Id57df3ff8127601429426c177a10e8eaec30c504
Also match on
local foo="$(bar)"
which hides the return value of "bar" (this popped up in a devstack
review).
Change-Id: I18e985d3e4cf87eb7ac54d6341355ee8b30d9349
Emacs in particluar does some indenting where it will try to align
continued lines up with the first argument, e.g.
a_long_command arg1 \
arg2 arg3
Our current check will just barf on this when the offset isn't a
multiple of 4. By passing "logical_line" to the offset checker, we
can find the first argument on the first line, and allow the whole
thing through if everything lines up.
Change-Id: I7f3369e4888353d2ba4ba2e48f3aaec4d1135b53
Rework things to collect continuation lines into "logical_lines". We
convert this to an array (holding all lines of the continuation) for
simplicity.
For now, retain the status quo by running the existing checks over
each line as before. However, this gives us the flexibility to do
different things for continuations, like allow different offsets.
Change-Id: I7bee246c9fd77ccdc4be3c2ba605d54d6fb81c86
I noticed that we end up treating a heredoc as one big logical line,
then passing it through things like the line-length check. So
cat <<EOF
this is normal lines
that get picked up as a long line!
EOF
end up triggering the long-line exception ... clearly not what is
intended.
In fact, there's not much we can do with heredocs. They are usually
some weird syntax for a config file, or something else you're writing
out in bulk. Often they have offsets that just don't match what we
want, etc.
Thus most logical thing to do seems to be to just ignore whatever is
in the heredoc.
I also noticed we don't handle <<'EOF', which is another common idiom,
so add that to the regex. Also add a test-case to ensure we're
ignoring the heredoc contents.
Change-Id: I2e3d66f27ff4c0d1f542511ca3e19c29a596896f
Currently E012 (detect if heredoc doesn't end) basically doesn't work;
it relies on having multiple files specified to check. The logic is
currently that if a heredoc is open and we start a new-file, we missed
it.
As we even say in the comments, bash will warn about this. Luckily,
"bash -n" does pop out this warning when we forget to close a
heredoc.
So modify the existing bash syntax check to catch this too. Because
it's a warning, bash doesn't exit with !0, so rework things to just
parse output in all cases. I also found a bit of inconsistency with
output, as described in the comments.
Remove the existing check, and add a testcase.
Change-Id: I292a926d3297a283f74f7d47b7c7aa3c42c9f030
argparse was external in python 2.6 but not anymore, remove it from
requirements.
This should help with pip 8.0 that gets confused in this situation.
Installation of the external argparse is not needed.
Change-Id: Ib7e74912b36c1b5ccb514e31fac35efeff57378d
This patch removes `MANIFEST.in` file as pbr generates a sensible
manifest from git files and some standard files and it removes
the need for an explicit `MANIFEST.in` file.
Change-Id: I26c60c0235a959ba565693df0b7f05b77ccdd530
as of mitaka, the infra team won't have the resources available to
reasonably test py26, also the oslo team is dropping py26 support
from their libraries. sine we rely on oslo for a lot of our work,
Change-Id: I352fe202a1f954b52e8e9ef8bc0a20f729ac17be
When bashate is run in a non-posix locale environment,
the bash syntax check is failing since bash does not
returns the localized error message, which we can
not detect. Enforce a known good locale.
Change-Id: I4a9423927eb7d526fd3549aef2305088b51d9b1f
I noticed this in I21d3c2ad7a020a5ab02dc1ab532feae70b718892 ; if you
have a tab-indent, we don't need to warn that the same line is also
not indented correctly
Change-Id: If0499126fc64861de971f851e2715d4379bd9dee
`bash -n` will do a shallow syntax check on a bash script,
just checking that the script parses. It's possible to have
scripts that pass all bashate style checks, but don't actually
run because of a syntax error, so this adds error code E040
and reports the syntax errors that `bash -n` outputs.
Change-Id: Ib128c54493221e71cca19a497a6efc4f5fc368c1
The return status of "local" is always 0, so something like
local foo=$(failing command)
doesn't trigger a failure under "set -e". Missing "failing command"'s
failure has been a source of problems within devstack.
This is added as a warning
Change-Id: Ia0957b47187c3dcadd46154b17022c4213781112
This mimics the widely accepted convention from PEP8 and many other
places that lines longer than 79 columns can not only cause problems
when reading/writing code, but also often indicate a bad smell,
e.g. too many levels of indentation due to overly complex functions
which require refactoring into smaller chunks.
Change-Id: Ic2532676e46e93f129d590d1fa7a044ef65f50fb
Take care of this TODO by renaming our non-constant
instance variables to something more descriptive.
Change-Id: I8ab9eb41180ef9c55c75bccb627413f2b717d217