diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 701b6815c..5c7b21151 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -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/) + # -PR- # - # 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: - # - # -PR- - # - # For PRs it is the merge commit (`refs/pull//merge`). For - # branches, the tip. + # For branches, it's just the git branch tip hash. # For pull requests, refs/pull//merge was just checked out # by so HEAD will refer to the right revision. For branches, HEAD