ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-19 13:07:56 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

most of those words proved irrelevant

Browse Source
This commit is contained in:
Jean-Paul Calderone 2021-01-07 18:24:57 -05:00
parent 3b8df95e3e
commit 709823e562
1 changed files with 6 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
.github/workflows/ci.yml vendored
View File

@ -104,7 +104,7 @@ jobs:
#
# 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.
# 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.
@ -114,67 +114,13 @@ jobs:
# is on CircleCI. CircleCI documentation says this about
# CIRCLE_WORKFLOW_ID:
#
# A unique identifier for the workflow instance of the current
# job. This identifier is the same for every job in a given
# workflow instance.
# 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:
#
# (from https://circleci.com/docs/2.0/env-vars/)
# <GIT MERGE COMMIT HASH>-PR-<PR NUM>
#
# A CircleCI workflow is roughly "the group of jobs run for a
# particular commit". There are exceptions to this but maybe we can
# ignore them.
#
# The only over hints we get from Coveralls about "build_num" are:
#
# * An example value of `1234`
#
# * Another example value of `$BUILD_NUMBER` where BUILD_NUMBER is
# not defined anywhere.
#
# Starting from the CircleCI workflow example, then, and looking at
# the environment variables GitHub Actions offers
# (https://docs.github.com/en/free-pro-team@latest/actions/reference/environment-variables#default-environment-variables) there are two of interest:
#
# * GITHUB_RUN_ID - A unique number for each run within a
# repository. This number does not change if you re-run the
# workflow run.
#
# * GITHUB_RUN_NUMBER - A unique number for each run of a particular
# workflow in a repository. This number begins at 1 for the
# workflow's first run, and increments with each new run. This
# number does not change if you re-run the workflow run.
#
# These seem to offer approximately the same value and only differ
# on whether they will be unique for the project as a whole or just
# for this particular workflow ("ci", as defined by this file).
#
# Unfortunately neither of them changes if a workflow is re-run.
# This differs from the behavior of CircleCI's CIRCLE_WORKFLOW_ID
# where a new value is assigned if a workflow is re-run.
#
# The consequence of this would seem to be that multiple runs of a
# GitHub Actions workflow will have their coverage reported to the
# same job. And since we eventually "finish" a job, later runs
# would be discarded (I suppose).
#
# There doesn't seem to be a way to do any better, though.
#
# However, we have the further constraint that our build_num must
# agree with whatever coveralls-python has selected. An inspection
# of the coveralls-python source suggests that GITHUB_RUN_ID is
# used:
#
# * https://github.com/coveralls-clients/coveralls-python/blob/a9b36299ce9ba3bb6858700781881029d82e545d/coveralls/api.py#L105-L109
# * https://github.com/coveralls-clients/coveralls-python/blob/a9b36299ce9ba3bb6858700781881029d82e545d/coveralls/api.py#L54-L59
#
# However, observation of the coveralls.io web interface, logs from
# the coveralls command in action, and experimentation suggests the
# value instead is something more like:
#
# <GIT COMMIT HASH>-PR-<PR NUM>
#
# For PRs it is the merge commit (`refs/pull/<PR>/merge`). For
# branches, the tip.
# 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