Codecraft 🚧

Codecraft 🚧#

Estimated reading time: 7 minutes

Here we provide some high-level maintenance guidelines, best practice and all-round sage advice for contributors.

Auto-Approve Workflow#

Reference:

  • .github/CODEOWNERS

  • .github/workflows/ci-auto-approve.yml

The main branch of the upstream repository has adopted the branch protection rule which requires a pull-request review approval from a designated code owner.

Trusted collaborators with sufficient privileges may request automated approval from the @geovista-bot by submitting a @geovista-bot auto-approve comment within a pull-request.

@bjlittle has exclusive privileges pro tempore, pending governance policy formulation on geovista membership of the SciTools organisation.

However, trusted collaborators have sufficient privileges to request @geovista-bot approval of third-party bot generated pull-requests.

Dependabot#

Reference:

  • .github/dependabot.yml

  • .github/workflows/*.yml (github-actions)

  • requirements/pypi-*.txt (pip)

  • pyproject.toml (pip, pixi)

We use Dependabot automation to maintain cooldown period dependency version updates for both the github-actions and pip ecosystems.

Note that we adhere to the default unpinned-uses (zizmor v1.20.0) audit policy for github-actions which requires hash-pinning on all actions.

We adopt a minor pinning-strategy for pip ecosystem package dependencies and semver (default) for our pixi package dependencies.

注意

We heavily rely on dependabot to inform us of the constant version updates to our package dependencies available in the pip ecosystem.

When merging an automated chore pull-request from dependabot ensure to confirm whether any associated pixi package version pins also require to be updated.

If so, then raise a separate follow-on pull-request.

Generative AI#

We follow the Python Developer's Guide on the use of generative AI tools for contributing to Python projects.

In general, we recommend that contributors:

  • disclose the use of generative AI tools in their contributions, including the specific tools used and the extent of their involvement

  • review, edit and test any content generated by AI tools to ensure it meets the quality standards of the project and does not introduce unintended behavior or vulnerabilities

  • honour the intellectual property rights of others and avoid using AI-generated content that may infringe on copyrights or licenses

We respect the use of generative AI tools as a means to enhance productivity and creativity, but we also expect contributors to use these tools responsibly and ethically.

Simply put, a contributor is responsible for their contribution. We ❤️ quality contributions.

GitHub Collaboration Model#

We recommend that trusted collaborators adopt the shared-repository workflow, whereby you branch directly within the upstream repository and then open a pull-request from that branch.

        ---
title: bjlittle / geovista
config:
   theme: base
---
gitGraph
   commit id: "46b4308"
   commit id: "3046ae3"
   branch feature
   checkout feature
   commit id: "e4010dc"
   commit id: "f31bc89"
   checkout main
   commit id: "0c135fa"
   branch bug-fix
   commit id: "d86b85b"
   checkout main
   merge feature
   commit id: "main"

Fig. 9: Shared-Repository Workflow#

This is opposed to the forking workflow. That involves creating your own fork of the upstream repository, pushing branches to your fork, then opening a pull-request back to upstream. This workflow is typically adopted by external collaborators.

The main benefits of the shared-repository workflow are:

  • smoother collaboration - your colleagues can easily checkout your branch, review and even push fixes

  • full CI/CD access - your pull-request gets the same runners, secrets, and environments as upstream

Additionally, this workflow mirrors the development model adopted by the pyvista trusted collaborators.

On this page