You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: community/github/continuous-integration.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@ free from errors or issues related to the specific checks that have passed.
22
22
23
23
***Red X's**: These indicate that the code has failed the associated CI checks. This means there are issues that need to be addressed before the code can be merged. The issues could be related to code style, formatting, tests, or other criteria specified by the CI configuration.
24
24
25
-
#### If a CI check is red:
25
+
#### If a CI check is red
26
26
27
27
1.**Click on "Details"** next to the failed check to get more information about the failure.
28
28
2.**Review the logs or output** provided to understand what went wrong.
@@ -39,7 +39,6 @@ If you don't know who to ping, no worries. Someone from the pyOpenSci organizati
39
39
Generally we require a single passing approval in order to merge a pull request. However, in some cases, if you are a pyOpenSci staff member or community member with admin / write access, it could be the case that you need to merge something immediately (i.e. fixing a small piece of breaking code, a spelling error, or adding a new piece of content that has already been agreed upon).
40
40
:::
41
41
42
-
43
42
## CI and outside contributors
44
43
45
44
If someone from outside of the pyOpenSci organization submits a pull request, then someone within the organization needs to approve and run CI. If you
@@ -48,14 +47,15 @@ have those super powers, please go ahead and allow CI to run for new contributor
48
47
Next to each CI step that was run, there is a details button. If you click on that link, it will give you more information about what has run / not run as expected in the build.
49
48
50
49
## Website CI checks
50
+
51
51
All of our website repositories have several CI builds including:
52
52
53
53
1. A link checker
54
54
2.`htmlproofer`, which checks both links and alt tags, as well as images
55
55
3. a CI build that shows you what the rendered site looks like when built online. Currently we are using [CircleCI](https://circleci.com/) for a live rendered build, as CircleCI allows for in-browser website build checks. GitHub requires you to download, unzip and view and archive with the build site locally.
56
56
57
-
58
57
(pre-commit-ci)=
58
+
59
59
## About the Pre-Commit CI Bot
60
60
61
61
The [Pre-commit CI bot](https://pre-commit.ci/) is a continuous integration service that automatically
@@ -100,7 +100,7 @@ To setup the bot in a new repository:
100
100
101
101
1.**Enable pre-commit.ci** on your repository through the
102
102
[pre-commit.ci website](https://pre-commit.ci/).
103
-
2. The bot will automatically run checks and apply fixes on pull requests.
103
+
2. The pre-commit.ci bot will automatically run checks and apply fixes on pull requests.
104
104
3. Review the bot's output and ensure all checks pass before merging your code.
105
105
106
106
This approach ensures that all contributions meet our pyOpenSci code and
This repository contains code and content that builds and publishes our pyOpenSci website. The website, [pyOpenSci](https://www.pyopensci.org/), is hosted on GitHub and
49
-
uses the [Jekyll Minimal Mistakes](https://mmistakes.github.io/minimal-mistakes/) theme. The Python packages page, contributor page and peer review team page are all updated automagically using a
50
-
GitHub action workflow that is supported by the pyosMeta Python package discussed above. The workflow runs every other week but can be triggered manually as a **workflow
51
-
dispatch**.
51
+
This repository contains code and content that builds and publishes our
52
+
pyOpenSci website. The website, [pyOpenSci](https://www.pyopensci.org/), is
53
+
hosted on GitHub and uses the [Jekyll Minimal
54
+
Mistakes](https://mmistakes.github.io/minimal-mistakes/) theme. The Python
55
+
packages page, contributor page, and peer review team page are all updated
56
+
automatically using a GitHub action workflow that is supported by the pyosMeta
57
+
Python package discussed above. The workflow runs every other week but can be
58
+
triggered manually as a **workflow dispatch**.
52
59
53
60
### Critical CI workflows in this repository
54
61
55
-
The [contributor workflow action](https://github.com/pyOpenSci/pyopensci.github.io/blob/main/.github/workflows/update-contribs-reviews.yml) is a custom GitHub
56
-
action that is used to update the following website pages:
**Platform:** Sphinx book template that builds on top of the pydata_sphinx_theme
90
101
91
-
All of our pyOpenSci Sphinx books (handbook, packaging guide, software review guide ) have been customized to match our pyOpenSci branding. This repo contains the start of a Sphinx theme that will incorporate all of our branding, so we do not have to manually apply the branding and update it individually in each repo. Instead, we can update branding in the theme and it will be applied across all of our repositories that use the theme.
102
+
All of our pyOpenSci Sphinx books (handbook, packaging guide, software review
103
+
guide) have been customized to match our pyOpenSci branding. This repo contains
104
+
the start of a Sphinx theme that will incorporate all of our branding, so we do
105
+
not have to manually apply the branding and update it individually in each repo.
106
+
Instead, we can update branding in the theme, and it will be applied across all
107
+
of our repositories that use the theme.
92
108
93
-
Creating a theme was inspired by [Chris Holdgraf's](https://chrisholdgraf.com/) 2i2c Sphinx theme.
Copy file name to clipboardExpand all lines: community/github/pull-requests.md
+13-12Lines changed: 13 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ New pull requests should:
9
9
* be created from a fork rather than the pyOpenSci owned parent repository.
10
10
* never be submitted from the `main` branch of your fork.
11
11
12
-
Authors of new pull requests should, whenever possible, do their best to create clean pull requests.
12
+
Authors of new pull requests should, whenever possible, do their best to create clean pull requests.
13
13
14
14
A clean pull request:
15
15
@@ -21,9 +21,9 @@ A clean pull request:
21
21
Review your own pull request before asking someone else to review it for you. You might be surprised that you notice things in the pull request that you didn't notice when working on the content locally.
22
22
:::
23
23
24
-
### Pull request content
24
+
### Pull request content
25
25
26
-
Below are some guidelines for pull request content. Clean pull requests lead to simpler reviews & faster merging!
26
+
Below are some guidelines for pull request content. Clean pull requests lead to simpler reviews & faster merging!
27
27
28
28
1.**Keep It Small**: Aim for one logical change per pull request to simplify review.
29
29
1.**Create a descriptive PR Title and Summary**: Clearly state what the PR achieves and why, including any related issue numbers or discussions.
@@ -39,8 +39,9 @@ Below are some guidelines for pull request content. Clean pull requests lead to
39
39
1.**Keep your branch updated**: Regularly rebase your fork from the main branch (if possible) to avoid / clean up any merge conflicts and to keep your PR up to date.
40
40
41
41
:::{info}
42
+
42
43
*[tips for better pull requests](https://opensource.com/article/18/6/anatomy-perfect-pull-request)
43
-
* pyOpenSci has also enabled an "update branch" feature in the pull request, which will update your branch to be in sync with main. In most cases, this creates a merge commit rather than a rebase.
44
+
* pyOpenSci has also enabled an "update branch" feature in the pull request, which will update your branch to be in sync with main. In most cases, this creates a merge commit rather than a rebase.
44
45
:::
45
46
46
47
### Regular vs New Contributors
@@ -68,7 +69,6 @@ The above process is often implemented on a case-by-case basis depending on the
68
69
:::{todo}
69
70
Did we address these questions above??
70
71
71
-
72
72
What are the expectations for an external contributor?
73
73
What should they have done locally?
74
74
Do we expect someone to have done all the wrangling with Ruby and Jekyll?
@@ -102,14 +102,14 @@ specified style and format rules before it gets committed to the repository.
102
102
We generally use the following hooks:
103
103
104
104
***Autoformat**: Makes sure files end in a newline and only a newline.
105
-
-`end-of-file-fixer`
105
+
*`end-of-file-fixer`
106
106
***Lint**: Check for files with names that would conflict on a
107
107
case-insensitive filesystem like MacOS HFS+ or Windows FAT.
108
-
-`check-case-conflict`
108
+
*`check-case-conflict`
109
109
***Whitespace**: Clean up trailing white space at the end of individual lines.
110
-
-`trailing-whitespace`
110
+
*`trailing-whitespace`
111
111
***Spelling**: Check for spelling issues within the repository.
112
-
-`codespell`
112
+
*`codespell`
113
113
114
114
Setting up pre-commit locally is optional because we have the pre-commit bot
115
115
setup in our CI workflows. However, if you are a pyOpenSci staff member regularly contributes, we suggest that you set it up locally in our repos to ensure
@@ -124,17 +124,18 @@ To set up pre-commit locally, follow these steps:
124
124
```bash
125
125
pip install pre-commit
126
126
```
127
+
127
128
2. From the root of the pyOpenSci repository that you wish to run pre-commit
128
129
hooks on, run
129
130
130
131
```bash
131
132
pre-commit install
132
133
```
134
+
133
135
This will install all of the hooks that pyOpenSci has setup for that repository.
134
136
Most often there is a spell checker, and several markdown file formatters, which
135
137
will remove excess white space.
136
138
137
-
138
139
3. To run pre-commit on all files in the repository -
139
140
140
141
```bash
@@ -174,6 +175,7 @@ contributors across all of our GitHub repositories. Contributor information
174
175
is then published on [our website](https://www.pyopensci.org/our-community/index.html#pyopensci-community-contributors).
175
176
176
177
### Who we acknowledge
178
+
177
179
pyOpenSci is liberal in acknowledging all contributions, regardless of their size. When
178
180
someone new submits an issue or PR, add them as a contributor to the repo using
179
181
the bot.
@@ -193,18 +195,17 @@ When you add a user, the bot will open a pull request that can be squashed
193
195
and merged. Once merged, their profile image and name will appear in the
194
196
README file of that repository.
195
197
196
-
197
198
pyOpenSci then has an automated build that will parse contributors across all of
198
199
our repos, adding them to
199
200
the contributor list and noting the type(s) of contributions that they have made
200
201
(e.g., packaging guide, peer review guide).
201
202
202
203
:::{todo}
204
+
203
205
## GitHub & CI
204
206
205
207
* CI (Continuous integration) will be run on each new commit added to all of our public repositories (that have content).
206
208
207
-
208
209
### Permissions to run CI
209
210
210
211
In general, things are setup so CI doesn’t run automagically for new contributors. Rather, someone with triage rights will need to approve the workflow to run by hitting the approve and run button that will appear (see image below). We have things set up this way to avoid spam PRs and commits that will abuse our CI use. We could potentially adjust in the future, but also can adjust by allowing more people with “access levels” that can approve CI.
0 commit comments