FilesExpand file tree

 main

/

pytest-remote-data.yml

Copy path

View runs

Blame

More file actions

Blame

More file actions

Latest commit

 

History

History

History

111 lines (100 loc) · 4.96 KB

 main

/

pytest-remote-data.yml

Copy path

Top

File metadata and controls

• Code
• Blame

111 lines (100 loc) · 4.96 KB

Raw

Copy raw file

Download raw file

Open symbols panel

Edit and raw actions

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"]

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@v2

with:

fail_ci_if_error: true

verbose: true

flags: remote-data # flags are configured in codecov.yml