|
| 1 | +# A secondary test job that only runs the iotools tests if explicitly requested |
| 2 | +# (for pull requests) or on a push to the master branch. |
| 3 | +# Because the iotools tests require GitHub secrets, we need to be careful about |
| 4 | +# malicious PRs accessing the secrets and exposing them externally. |
| 5 | +# |
| 6 | +# We prevent this by only running this workflow when a maintainer has looked |
| 7 | +# over the PR's diff and verified that nothing malicious seems to be going on. |
| 8 | +# The maintainer then adds the "remote-data" label to the PR, which will then |
| 9 | +# trigger this workflow via the combination of the "on: ... types:" |
| 10 | +# and "if:" sections below. The first restricts the workflow to only run when |
| 11 | +# a label is added to the PR and the second requires one of the PR's labels |
| 12 | +# is the "remote-data" label. Technically this is slightly different from |
| 13 | +# triggering when the "remote-data" label is added, since it will also trigger |
| 14 | +# when "remote-data" is added, then later some other label is added. Maybe |
| 15 | +# there's a better way to do this. |
| 16 | +# |
| 17 | +# But wait, you say! Can't a malicious PR get around this by modifying |
| 18 | +# this workflow file and removing the label requirement? I think the answer |
| 19 | +# is "no" as long as we trigger the workflow on "pull_request_target" instead |
| 20 | +# of the usual "pull_request". The difference is what context the workflow |
| 21 | +# runs inside: "pull_request" runs in the context of the fork, where changes |
| 22 | +# to the workflow definition will take immediate effect, while "pull_request_target" |
| 23 | +# runs in the context of the main pvlib repository, where the original (non-fork) |
| 24 | +# workflow definition is used instead. Of course by switching away from the fork's |
| 25 | +# context to keep our original workflow definitions, we're also keeping all the |
| 26 | +# original code, so the tests won't be run against the PR's new code. To fix this |
| 27 | +# we explicitly check out the PR's code as the first step of the workflow. |
| 28 | +# This allows the job to run modified pvlib & pytest code, but only ever via |
| 29 | +# the original workflow file. |
| 30 | +# So long as a maintainer always verifies that the PR's code is not malicious prior to |
| 31 | +# adding the label and triggering this workflow, I think this should not present |
| 32 | +# a security risk. |
| 33 | +# |
| 34 | +# Note that this workflow can be triggered again by removing and re-adding the |
| 35 | +# "remote-data" label to the PR. |
| 36 | +# |
| 37 | +# Note also that "pull_request_target" is also the only way for the secrets |
| 38 | +# to be accessible in the first place. |
| 39 | +# |
| 40 | +# Further reading: |
| 41 | +# - https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ |
| 42 | +# - https://i.8713187.xyzmunity/t/can-workflow-changes-be-used-with-pull-request-target/178626/7 |
| 43 | + |
| 44 | +name: pytest-remote-data |
| 45 | + |
| 46 | +on: |
| 47 | + pull_request_target: |
| 48 | + types: [labeled] |
| 49 | + push: |
| 50 | + branches: |
| 51 | + - master |
| 52 | + |
| 53 | +jobs: |
| 54 | + test: |
| 55 | + |
| 56 | + strategy: |
| 57 | + fail-fast: false # don't cancel other matrix jobs when one fails |
| 58 | + matrix: |
| 59 | + python-version: [3.6, 3.7, 3.8, 3.9] |
| 60 | + suffix: [''] # the alternative to "-min" |
| 61 | + include: |
| 62 | + - python-version: 3.6 |
| 63 | + suffix: -min |
| 64 | + |
| 65 | + runs-on: ubuntu-latest |
| 66 | + if: (github.event_name == 'pull_request_target' && contains(github.event.pull_request.labels.*.name, 'remote-data')) || (github.event_name == 'push') |
| 67 | + |
| 68 | + steps: |
| 69 | + - uses: actions/checkout@v3 |
| 70 | + if: github.event_name == 'pull_request_target' |
| 71 | + # pull_request_target runs in the context of the target branch (pvlib/master), |
| 72 | + # but what we need is the hypothetical merge commit from the PR: |
| 73 | + with: |
| 74 | + ref: "refs/pull/${{ github.event.number }}/merge" |
| 75 | + |
| 76 | + - uses: actions/checkout@v2 |
| 77 | + if: github.event_name == 'push' |
| 78 | + |
| 79 | + - name: Set up conda environment |
| 80 | + uses: conda-incubator/setup-miniconda@v2 |
| 81 | + with: |
| 82 | + activate-environment: test_env |
| 83 | + environment-file: ${{ env.REQUIREMENTS }} |
| 84 | + python-version: ${{ matrix.python-version }} |
| 85 | + auto-activate-base: false |
| 86 | + env: |
| 87 | + # build requirement filename. First replacement is for the python |
| 88 | + # version, second is to add "-min" if needed |
| 89 | + REQUIREMENTS: ci/requirements-py${{ matrix.python-version }}${{ matrix.suffix }}.yml |
| 90 | + |
| 91 | + - name: List installed package versions |
| 92 | + shell: bash -l {0} # necessary for conda env to be active |
| 93 | + run: conda list |
| 94 | + |
| 95 | + - name: Run tests |
| 96 | + shell: bash -l {0} # necessary for conda env to be active |
| 97 | + env: |
| 98 | + # copy GitHub Secrets into environment variables for the tests to access |
| 99 | + NREL_API_KEY: ${{ secrets.NRELAPIKEY }} |
| 100 | + BSRN_FTP_USERNAME: ${{ secrets.BSRN_FTP_USERNAME }} |
| 101 | + BSRN_FTP_PASSWORD: ${{ secrets.BSRN_FTP_PASSWORD }} |
| 102 | + run: pytest pvlib/tests/iotools pvlib/tests/test_forecast.py --cov=./ --cov-report=xml --remote-data |
| 103 | + |
| 104 | + - name: Upload coverage to Codecov |
| 105 | + if: matrix.python-version == 3.6 && matrix.suffix == '' |
| 106 | + uses: codecov/codecov-action@v2 |
| 107 | + with: |
| 108 | + fail_ci_if_error: true |
| 109 | + verbose: true |
| 110 | + flags: remote-data # flags are configured in codecov.yml |
0 commit comments