Merge 73c6299 into a4a8a22

tahoe-lafs · Mar 8, 2021 · 391a8a3 · 391a8a3
2 parents a4a8a22 + 73c6299
commit 391a8a3
Show file tree

Hide file tree

Showing 2 changed files with 87 additions and 69 deletions.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -19,9 +19,15 @@ jobs:
       matrix:
         os:
           - macos-latest
+          - ubuntu-latest
           - windows-latest
         python-version:
           - 2.7
+          - 3.6
+        exclude:
+          # Testing with Python 3.6 on Windows does not work yet.
+          - os: windows-latest
+            python-version: 3.6
 
     steps:
 
@@ -87,10 +93,12 @@ jobs:
       # Action for this, as of Jan 2021 it does not support Python coverage
       # files - only lcov files.  Therefore, we use coveralls-python, the
       # coveralls.io-supplied Python reporter, for this.
-      - name: "Report Coverage to Coveralls"
+
+      - name: "Report Coverage to Coveralls (python -m coveralls)"
         run: |
-          pip install coveralls
-          python -m coveralls
+          pip3 install --upgrade coveralls
+          python3 -m coveralls --version
+          python3 -m coveralls
         env:
           # Some magic value required for some magic reason.
           GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
@@ -118,75 +126,85 @@ jobs:
     # the coverage reports are broken and someone added more
     # coverage-collecting jobs to this workflow but didn't update this, that's
     # why.
-    needs:
-      - "coverage"
-    runs-on: "ubuntu-latest"
-    steps:
-      - name: "Check out Tahoe-LAFS sources"
-        uses: "actions/checkout@v2"
+    needs: coverage
+    runs-on: ubuntu-latest
+    container: python:3-slim
 
-      - name: "Finish Coveralls Reporting"
+    steps:
+      - name: Indicate completion to coveralls.io
         run: |
-          # coveralls-python does have a `--finish` option but it doesn't seem
-          # to work, at least for us.
-          # https://github.com/coveralls-clients/coveralls-python/issues/248
-          #
-          # But all it does is this simple POST so we can just send it
-          # ourselves.  The only hard part is guessing what the POST
-          # parameters mean.  And I've done that for you already.
-          #
-          # Since the build is done I'm going to guess that "done" is a fine
-          # value for status.
-          #
-          # That leaves "build_num".  The coveralls documentation gives some
-          # hints about it.  It suggests using $CIRCLE_WORKFLOW_ID if your job
-          # is on CircleCI.  CircleCI documentation says this about
-          # CIRCLE_WORKFLOW_ID:
-          #
-          # Observation of the coveralls.io web interface, logs from the
-          # coveralls command in action, and experimentation suggests the
-          # value for PRs is something more like:
-          #
-          #    <GIT MERGE COMMIT HASH>-PR-<PR NUM>
-          #
-          # For branches, it's just the git branch tip hash.
-
-          # For pull requests, refs/pull/<PR NUM>/merge was just checked out
-          # by so HEAD will refer to the right revision.  For branches, HEAD
-          # is also the tip of the branch.
-          REV=$(git rev-parse HEAD)
-
-          # We can get the PR number from the "context".
-          #
-          # https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/webhook-events-and-payloads#pull_request
-          #
-          # (via <https://github.community/t/github-ref-is-inconsistent/17728/3>).
-          #
-          # If this is a pull request, `github.event` is a `pull_request`
-          # structure which has `number` right in it.
-          #
-          # If this is a push, `github.event` is a `push` instead but we only
-          # need the revision to construct the build_num.
-
-          PR=${{ github.event.number }}
-
-          if [ "${PR}" = "" ]; then
-              BUILD_NUM=$REV
-          else
-              BUILD_NUM=$REV-PR-$PR
-          fi
-          REPO_NAME=$GITHUB_REPOSITORY
-
-          curl \
-            -k \
-            https://coveralls.io/webhook?repo_token=$COVERALLS_REPO_TOKEN \
-            -d \
-            "payload[build_num]=$BUILD_NUM&payload[status]=done&payload[repo_name]=$REPO_NAME"
+          pip3 install --upgrade coveralls
+          python3 -m coveralls --version
+          python3 -m coveralls --finish
         env:
-          # Some magic value required for some magic reason.
-          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
-          # Help coveralls identify our project.
-          COVERALLS_REPO_TOKEN: "JPf16rLB7T2yjgATIxFzTsEgMdN1UNq6o"
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+    # steps:
+    #   - name: "Check out Tahoe-LAFS sources"
+    #     uses: "actions/checkout@v2"
+
+    #   - name: "Finish Coveralls Reporting"
+    #     run: |
+    #       # coveralls-python does have a `--finish` option but it doesn't seem
+    #       # to work, at least for us.
+    #       # https://github.com/coveralls-clients/coveralls-python/issues/248
+    #       #
+    #       # But all it does is this simple POST so we can just send it
+    #       # ourselves.  The only hard part is guessing what the POST
+    #       # parameters mean.  And I've done that for you already.
+    #       #
+    #       # Since the build is done I'm going to guess that "done" is a fine
+    #       # value for status.
+    #       #
+    #       # That leaves "build_num".  The coveralls documentation gives some
+    #       # hints about it.  It suggests using $CIRCLE_WORKFLOW_ID if your job
+    #       # is on CircleCI.  CircleCI documentation says this about
+    #       # CIRCLE_WORKFLOW_ID:
+    #       #
+    #       # Observation of the coveralls.io web interface, logs from the
+    #       # coveralls command in action, and experimentation suggests the
+    #       # value for PRs is something more like:
+    #       #
+    #       #    <GIT MERGE COMMIT HASH>-PR-<PR NUM>
+    #       #
+    #       # For branches, it's just the git branch tip hash.
+
+    #       # For pull requests, refs/pull/<PR NUM>/merge was just checked out
+    #       # by so HEAD will refer to the right revision.  For branches, HEAD
+    #       # is also the tip of the branch.
+    #       REV=$(git rev-parse HEAD)
+
+    #       # We can get the PR number from the "context".
+    #       #
+    #       # https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/webhook-events-and-payloads#pull_request
+    #       #
+    #       # (via <https://github.community/t/github-ref-is-inconsistent/17728/3>).
+    #       #
+    #       # If this is a pull request, `github.event` is a `pull_request`
+    #       # structure which has `number` right in it.
+    #       #
+    #       # If this is a push, `github.event` is a `push` instead but we only
+    #       # need the revision to construct the build_num.
+
+    #       PR=${{ github.event.number }}
+
+    #       if [ "${PR}" = "" ]; then
+    #           BUILD_NUM=$REV
+    #       else
+    #           BUILD_NUM=$REV-PR-$PR
+    #       fi
+    #       REPO_NAME=$GITHUB_REPOSITORY
+
+    #       curl \
+    #         -k \
+    #         "https://coveralls.io/webhook?repo_name=$GITHUB_REPOSITORY&repo_token=${{ secrets.GITHUB_TOKEN }}" \
+    #         -d \
+    #         "payload[build_num]=$GITHUB_RUN_NUMBER&payload[status]=done"
+    #     env:
+    #       # Some magic value required for some magic reason.
+    #       GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
+    #       # Help coveralls identify our project.
+    #       COVERALLS_REPO_TOKEN: "JPf16rLB7T2yjgATIxFzTsEgMdN1UNq6o"
 
   integration:
     runs-on: ${{ matrix.os }}

diff --git a/newsfragments/3616.minor b/newsfragments/3616.minor