Merge branch 'kernelci:main' into args

kernelci · Mar 22, 2023 · 8f43bdf · 8f43bdf
2 parents 12a24f2 + cfcfe8f
commit 8f43bdf
Show file tree

Hide file tree

Showing 5 changed files with 82 additions and 18 deletions.
diff --git a/cloud b/cloud
@@ -1234,6 +1234,7 @@ function cloud_function_withdraw() {
 # Output deployment environment for Cloud Functions
 # Args: --format=yaml|sh
 #       --log-level=NAME
+#       --optimize=PYTHONOPTIMIZE
 #       --heavy-asserts=true|false
 #       --new-topic=NAME --new-load-subscription=NAME
 #       --updated-publish=true|false
@@ -1249,6 +1250,7 @@ function cloud_function_withdraw() {
 function cloud_functions_env() {
     params="$(getopt_vars format \
                           log_level \
+                          optimize \
                           heavy_asserts \
                           new_topic new_load_subscription \
                           updated_publish updated_topic \
@@ -1264,6 +1266,7 @@ function cloud_functions_env() {
     eval "$params"
     declare -A env=(
         [KCIDB_LOG_LEVEL]="$log_level"
+        [PYTHONOPTIMIZE]="${optimize}"
         [KCIDB_LOAD_QUEUE_TOPIC]="$new_topic"
         [KCIDB_LOAD_QUEUE_SUBSCRIPTION]="$new_load_subscription"
         [KCIDB_LOAD_QUEUE_MSG_MAX]="256"
@@ -1655,6 +1658,7 @@ function escape_whitespace() {
 #       --smtp-mocked=true|false
 #       --test=true|false
 #       --log-level=NAME
+#       --optimize=PYTHONOPTIMIZE
 #       --heavy-asserts=true|false
 #       --updated-publish=true|false
 #       --submitters=WORDS
@@ -1671,6 +1675,7 @@ function execute_command() {
                           smtp_mocked \
                           test \
                           log_level \
+                          optimize \
                           heavy_asserts \
                           updated_publish \
                           submitters \
@@ -1807,6 +1812,7 @@ function execute_command() {
 
     declare -r -a env_args=(
         --log-level="$log_level"
+        --optimize="$optimize"
         --heavy-asserts="$heavy_asserts"
         --new-topic="$new_topic"
         --new-load-subscription="$new_load_subscription"
@@ -1974,6 +1980,9 @@ function usage_deploy() {
     echo "    --log-level=NAME"
     echo "              Specify Python log level NAME for Cloud Functions."
     echo "              Default is INFO."
+    echo "    --optimize=PYTHONOPTIMIZE"
+    echo "              Specify a value for PYTHONOPTIMIZE to be added to the environment"
+    echo "              Default is an empty string."
     echo "    --heavy-asserts"
     echo "              Enable heavy assertion checking in deployment."
     echo "    --mute-updates"
@@ -2017,6 +2026,9 @@ function usage_env() {
     echo "    --log-level=NAME"
     echo "              Specify Python log level NAME for Cloud Functions."
     echo "              Default is INFO."
+    echo "    --optimize=PYTHONOPTIMIZE"
+    echo "              Specify a value for PYTHONOPTIMIZE to be added to the environment"
+    echo "              Default is an empty string."
     echo "    --heavy-asserts"
     echo "              Enable heavy assertion checking in deployment."
     echo "    --mute-updates"
@@ -2054,6 +2066,9 @@ function usage_shell() {
     echo "    --log-level=NAME"
     echo "              Specify Python log level NAME for Cloud Functions."
     echo "              Default is INFO."
+    echo "    --optimize=PYTHONOPTIMIZE"
+    echo "              Specify a value for PYTHONOPTIMIZE to be added to the environment"
+    echo "              Default is an empty string."
     echo "    --heavy-asserts"
     echo "              Enable heavy assertion checking in deployment."
     echo "    --mute-updates"
@@ -2168,7 +2183,7 @@ function execute() {
         fi
         if [[ $command == @(deploy|env|shell) ]]; then
             getopt_longopts+=",extra-cc:,smtp-to-addrs:"
-            getopt_longopts+=",log-level:,heavy-asserts,mute-updates"
+            getopt_longopts+=",log-level:,optimize:,heavy-asserts,mute-updates"
             if [[ $command == env ]]; then
                 getopt_longopts+=",format:"
             fi
@@ -2199,6 +2214,7 @@ function execute() {
     declare smtp_mocked="false"
     declare test="false"
     declare log_level="INFO"
+    declare optimize=""
     declare heavy_asserts="false"
     declare updated_publish="true"
     declare -a submitters=()
@@ -2215,6 +2231,7 @@ function execute() {
             --psql-password-file)
                 password_set_file psql_superuser "$2"; shift 2;;
             --log-level) log_level="$2"; shift 2;;
+            --optimize) optimize="$2"; shift 2;;
             --heavy-asserts) heavy_asserts="true"; shift;;
             --mute-updates) updated_publish="false"; shift;;
             --test) test="true"; shift;;
@@ -2285,6 +2302,7 @@ function execute() {
                     --smtp-mocked="$smtp_mocked" \
                     --test="$test" \
                     --log-level="$log_level" \
+                    --optimize="$optimize" \
                     --heavy-asserts="$heavy_asserts" \
                     --updated-publish="$updated_publish" \
                     --submitters="${submitters[*]@Q}" \

diff --git a/doc/developer_guide.md b/doc/developer_guide.md
@@ -25,6 +25,35 @@ Then make sure your PATH includes the `~/.local/bin` directory, e.g. with:
 Guidelines
 ----------
 
+### Commits
+
+When posting PRs, please keep one logical change per commit, and do not have
+more than one commit per a logical change. This makes it easier to review,
+think about, and manipulate changes. This way if you want to revert a change,
+you only need to revert a single commit. Same goes for merges across branches.
+
+For example, if you have to do a similar change across multiple files, make it
+a single commit. OTOH, if you're doing different changes on the same file, or
+even the same line, make them separate commits.
+
+Before asking for a review, please make sure the commits are in order, and
+don't keep amendments made on top of the previous review as separate commits -
+squash them.
+
+Please use [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood)
+when writing commit messages, i.e. as if giving a command for something to
+change. Keep subjects short and to the point, expand in the body of the commit
+message. This makes it easier to read, understand, and manipulate commit
+history. E.g. write "Add support for querying incidents", or even just
+"Support querying incidents", but not "Supported querying incidents", and not
+"Code to support querying incidents".
+
+Use "tags" in commit subjects to make them shorter and to indicate the scope
+of the change. E.g. instead of writing "Add documentation on commit
+requirements", write "doc: Describe commit requirements". Look at commit
+history of particular areas you're changing for reference on which tags to
+use, so they're consistent.
+
 ### I/O data validation
 
 When loading data into a database, the data should be "directly compatible"

diff --git a/doc/installation.md b/doc/installation.md
@@ -15,10 +15,6 @@ Where `<SOURCE>` is the location of the package source, e.g. a git repo:
 
     pip3 install --user git+https://github.com/kernelci/kcidb.git
 
-a (release) tag in a git repo:
-
-    pip3 install --user git+https://github.com/kernelci/kcidb.git@v9
-
 or a directory path:
 
     pip3 install --user .

diff --git a/doc/submitter_guide.md b/doc/submitter_guide.md
@@ -60,12 +60,15 @@ dashboard](https://kcidb.kernelci.org/).
 2\. Install KCIDB
 -----------------
 
-Pick a KCIDB [release][releases]. Latest would normally be best.
 
-Let's say you picked v9. Run this:
+KCIDB employs continuous integration and delivery, and aims to keep
+the code working at all times.
+
+Please install the latest version from GitHub:
+
 
 ```bash
-pip3 install --user 'git+https://[email protected]/kernelci/kcidb.git@v9'
+pip3 install --user 'git+https://[email protected]/kernelci/kcidb.git'
 ```
 
 Then make sure your PATH includes the `~/.local/bin` directory, e.g. with:
@@ -85,7 +88,7 @@ $ kcidb-query -d bigquery:playground_kcidb_01
 and submit an empty report:
 
 ```console
-$ echo '{"version":{"major":4,"minor":0}}' |
+$ echo '{"version":{"major":4,"minor":1}}' |
         kcidb-submit -p kernelci-production -t playground_kcidb_new
 ```
 
@@ -95,19 +98,18 @@ exit status.
 3\. Generate some report data
 -----------------------------
 
-KCIDB accepts data in JSON, described by a versioned schema. The
-`kcidb-schema` tool will output the current schema version. However, all tools
-will accept data complying with older schema versions, as a rule. Any
-exceptions to that will be mentioned in KCIDB release notes. Pipe your data
-into `kcidb-validate` tool to check if it will be accepted.
+`kcidb-schema` tool will output the current schema version.
+
+However, all tools will accept data complying with older schema versions. Pipe
+your data into `kcidb-validate` tool to check if it will be accepted.
 
 Here's a minimal report, containing no data:
 
 ```json
 {
     "version": {
         "major": 4,
-        "minor": 0
+        "minor": 1
     }
 }
 ```
@@ -153,9 +155,24 @@ checkout with one build and one test:
             "origin": "submitter"
         }
     ],
+    "issue": [
+        {
+            "id": "submitter:124853810",
+            "version": 1,
+            "origin": "submitter"
+        }
+    ],
+    "incident": [
+        {
+            "id": "submitter:1084645810",
+            "issue_id": "submitter:956769",
+            "origin": "submitter",
+            "issue_version": 0
+        }
+    ],
     "version": {
         "major": 4,
-        "minor": 0
+        "minor": 1
     }
 }
 ```
@@ -406,7 +423,6 @@ let you, kernel developers, and KCIDB developers see how it works, what
 changes/additions might be needed to both your data and KCIDB, and improve our
 reporting faster!
 
-[releases]: https://github.com/kernelci/kcidb/releases
 [datetime_format]: https://tools.ietf.org/html/rfc3339#section-5.6
 [tests]: https://github.com/kernelci/kcidb/blob/master/tests.yaml
 [dashboard]: https://kcidb.kernelci.org/

diff --git a/kcidb/tests/__init__.py b/kcidb/tests/__init__.py
@@ -24,4 +24,9 @@ def validate_main():
     schema.validate(catalog)
     if args.urls:
         for test in catalog.values():
-            requests.head(test['home'], timeout=60).raise_for_status()
+            try:
+                requests.head(test['home'], timeout=60).raise_for_status()
+            except requests.exceptions.SSLError:
+                requests.head(
+                    test['home'], timeout=60, verify=False
+                ).raise_for_status()