We're trying to get rid of this module and this is one of the last
users. It isn't really using anything from the module either, other
than the `api` GitHub instance (which it could easily create for itself
directly).
Let's use the GitHub methods directly for everything. One minor fix:
you close GitHub issues with PATCH, not POST.
Replace full LGPL/GPL/MIT/BSD license header with
SPDX-License-Identifier in all source files. This is more concise and
makes the license information machine readable.
Keep the full text of ISC for src/common/cockpitbase64.[hc], it's small
enough and only used in this pair of files. Also keep the CC-BY-SA
paragraph in pkg/storaged/icons/gnome-icons.jsx as explained in the
previous commit.
See https://reuse.software/spec-2.0/#2-include-a-copyright-notice-and-license-in-each-filehttps://issues.redhat.com/browse/COCKPIT-1742
https://gnome.org keeps failing with "403 Forbidden" when running in a
GitHub action, presumably due to some IP range (or User-Agent) ban? It
works fine locally.
We know that https://www.gnome.org is fine, so generalize our existing
ignore mechanism for example.com and add it to that list.
Fixes#21340
We'd like to run our executable python scripts using our new `pywrap`
feature as a better way to get their PYTHONPATH setup properly. This
script lives in our source tree, at a fixed relative location to each
script that we're interested in, but has no absolute system path.
The #!interpreter syntax does supports relative paths, but they are
resolved relative to the current working directory, not relative to the
file in which they appear, which makes this feature pretty useless.
There are some tricks we can do to get our designed 'relative'
behaviour, though.
Something like this works:
#!/usr/bin/env -S sh -c '"${0%/*}/pywrap" "$0"'
but it causes various file auto-detection schemes (including our own
test/static-code) to improperly conclude that this is a shell script,
rather than a Python script. (n)vim also gets it wrong for highlighting
and linting purposes.
Fortunately there's a somewhat longer, but still acceptable version of
this we can do in Python:
#!/usr/bin/python3 -cimport os, sys; os.execv(os.path.dirname(sys.argv[1]) + "/pywrap", sys.argv)
This fits well under our 118 column limit.
Note that unlike `sh`, the `-c` option in Python doesn't require the
script to be passed as a separate argument, which means we don't need to
use the non-POSIX splitting tricks of `/usr/bin/env -S`.
Note also: it appears as though our hardcoding of /usr/bin/python3 here
might be venv-unfriendly, but it's not: /usr/bin/python3 (which surely
exists) is used only for running this one tiny fragment of code. Our
pywrap script itself finds python3 in the path.
Let's move all of our previous users of `import parent` over to the new
approach.
We can remove a couple of `parent.py` symlinks we had lying
around, as well.
We also remove `parent.py` itself, since otherwise vulture complains
about it being unused. Subprojects will be forced to adjust on upgrade.
Remove a CodeQL exemption that was necessitated by our `import parent`
shenanigans.
Parse the URL and only compare the hostname against "example.com". Not
very relevant, but calms down CodeQL "Incomplete URL substring
sanitization" check.
Move user agent to the top as a constant.
Move the PatternFly exception also to the top by converting the
exceptions list into fnmatch patterns.
Get rid of the non-idiomatic use of /usr/bin/env to find python3.
Clean up some string formatting to use f-strings and be more generally
readable.
It seems that just `Mozilla/5.0` was not enough for https://bugzilla.mozilla.org
as it was returning `400 - Bad request`. Putting there something more
real makes it work again.
Fixes#16221
The reason that the files in test/verify/ don't need to do sys.path
hacks is because parent.py has been symlinked into that directory. Do
the same with the two other directories which contain scripts which need
such hacks, allowing a substantial cleanup.
Make some minor code adjustments to use the variables defined in
parent.py instead of the home-brew versions.
Add a somewhat dubious cwd= parameter to the `git grep` subprocess
invocation in tools/url-check. This is strictly correct (since we want
to check the base directory, regardless of the current directory when
the tool was invoked) but we're really doing as a convenient way to
avoid a message about an unused import.
This has no impact because it's done after all the imports. It's also
unprecedented: nothing else in the project does this, outside of the
run-tests scripts (which are in a bit of a different category, because
they import the testcases themselves).
Our recent changes to test-static-code were causing node_modules/ and
bots/ to be scanned. Steal some code from bots/ (thanks Matej) to make
sure we only scan files that are in git. That should also speed things
up a little bit.
This causes us to find a couple of new files, so make the usual tweaks
to fix those ones up.
If we're not in a git checkout, #skip the test.
