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