From 48987a5578c316752791517bca5d4d75a0a91698 Mon Sep 17 00:00:00 2001 From: Samuel Burnham <45365069+samuelburnham@users.noreply.github.com> Date: Thu, 15 Feb 2024 15:52:03 -0500 Subject: [PATCH] Cleanup & improve docs --- .github/workflows/codecov.yml | 8 ---- .github/workflows/nightly.yml | 3 ++ CONTRIBUTING.md | 79 ----------------------------------- README.md | 23 ++++++---- 4 files changed, 18 insertions(+), 95 deletions(-) delete mode 100644 .github/workflows/codecov.yml delete mode 100644 CONTRIBUTING.md diff --git a/.github/workflows/codecov.yml b/.github/workflows/codecov.yml deleted file mode 100644 index 30f249c..0000000 --- a/.github/workflows/codecov.yml +++ /dev/null @@ -1,8 +0,0 @@ -name: Generate and deploy Codecov results -on: - schedule: - - cron: '0 0 * * *' - -jobs: - codecov-grcov: - uses: lurk-lab/ci-workflows/.github/workflows/codecov.yml@main diff --git a/.github/workflows/nightly.yml b/.github/workflows/nightly.yml index f5e18ff..fd8983c 100644 --- a/.github/workflows/nightly.yml +++ b/.github/workflows/nightly.yml @@ -16,3 +16,6 @@ jobs: rust-version-check: uses: lurk-lab/ci-workflows/.github/workflows/rust-version-check.yml@main + + typos: + uses: lurk-lab/ci-workflows/.github/workflows/typos.yml@main diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 80a6b3f..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,79 +0,0 @@ -# Contributing to TEMPLATE - -We want to make contributing to this project as easy and transparent as possible. - -## Pull Requests -If you want to contribute a bug fix or feature to TEMPLATE, here's how to proceed: - -1. Fork the repo and create your branch from `main`. -2. If you've added code that should be tested, add tests. -3. If you've changed APIs, update the documentation. -4. Ensure the test suite passes. -5. Submit your pull-request, writing a clear description of its intended purpose, and linking any issues it addresses - -## Pull Request reviews - -The maintainers will review your pull request as soon as they can, and it can only be merged once it has at least one approval . The comments can be in several forms: - -- 'Comment' usually indicates the reviewer doesn't yet commit to approving your code but has important remarks to contribute. -- 'Request Changes' means changes need to be made before the reviewer approves at all. -- 'Approve' can be of two forms depending on the exact nature of the comments: - - Approval with no restrictions, or non-blocking comments indicates this can be merged by a maintainer. - - Approval with explicitly marked blocking comments means: "I don't need to review this again, but I need you (and trust you) to fix these issues first." - -## Merging a Pull-request - -A pull-request must meet certain criteria before it can be merged. - -1. If you are fine with a squash merge, your pull-request's final commit should have at least one approval from a reviewer - - EDIT AS NEEDED with CODEOWNER information -2. If you prefer a classic merge, the pull-request should meet the above conditions, and and it should be a fast-forward merge from main, which implies it must also be up-to-date. - -**Warning:** An up-to-date, rebased branch is required for a fast-forward merge. This means that your branch should not contain any merge commits: while we do not object to `Merge` as a pull-request merge method, we prefer the pull-request's history to be linear. To achieve this, you can update your local branch with `git pull --rebase` (see [doc](https://www.git-scm.com/docs/git-pull)). - -A maintainer will merge your pull-request (or their own) using one of the following methods: -1. The [GitHub's merge queue](https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/) with a squash merge strategy. This is the simplest workflow and always acceptable if you don't mind having a single commit. -2. If your commit history is carefully cleaned to remove unnecessary commits and ensure that each retained commit is meaningful, a repo admin may use the 'Merge' strategy. - -Please feel free to specify your preferred merge method in your PR summary. - -The implemented workflow is represented below, with rounded corners and dotted lines automatically handled by Github's merge queue: - -```mermaid -flowchart TD - # EDIT AS NEEDED with CODEOWNER information - Review{Is *last commit* of PR reviewed?} -->|Yes| Squash - Review --> |No| GReview[Get fresh review] - GReview --> Review - - Squash{Are you OK with Squash merge?} -->|Yes| MQueue(Merge queue) - Squash --> |No| Update{Is PR Up to date?} - - Update --> |Yes| Merge[Get a maintainer to merge it for you!] - Update --> |No| Rebase[Rebase & get fresh review] - Rebase --> Review - - Merge --> |It worked| Celebrate - Merge --> |Somebody pushed to main before maintainer| Rebase - - MQueue -.-> |PR squash-merges cleanly on main & passes CI| Celebrate - MQueue -.-> |Github merge queue found squash-merge or CI issue| Rebase -``` - -**Note:** In exceptional cases, we may preserve some messy commit history if not doing so would lose too much important information and fully disentangling is too difficult. We expect this would rarely apply. - -## Issues -We use GitHub issues to track public bugs. Please ensure your description is clear and has sufficient instructions to be able to reproduce the issue. - -## TEMPLATE Repository Organization and Dependency Management -- EDIT AS NEEDED - -### Where to Make Changes? -- EDIT AS NEEDED - -## For maintainers: Benchmarking -- EDIT AS NEEDED - -## License -By contributing to TEMPLATE, you agree that your contributions will be licensed under both [MIT](https://opensource.org/licenses/MIT) and [Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0) licenses. - diff --git a/README.md b/README.md index 168c033..f2688a3 100644 --- a/README.md +++ b/README.md @@ -1,20 +1,27 @@ # template-rust-lib Base template for a Rust library crate with CI, config files, and branch protection -## Notes -- The generated repo will have a protected `main` branch with the following required status checks: - - `linux-tests` - - `code-quality/msrv` - - `code-quality/lints` - - `code-quality/wasm-build` -- If the generated repo is public, it will enforce a merge queue using `squash and merge` by default -- Run the following after generating the new repo: +## Usage +- Generate a new repo via the green "Use this template" button +- Run the following to remove template language: ``` # Replace all occurrences with the desired library name $ grep -ir template . --exclude-dir .git --exclude deny.toml # Replace all occurrences as needed $ grep -r "EDIT AS NEEDED" . +# Then rewrite this `README` ``` +- Create a branch protection rule for `main` and enable the following as needed: + - Require a pull request before merging + - Require 1 approval + - Dismiss stale pull request approvals when new commits are pushed + - Require approval of the most recent reviewable push + - Require status checks to pass before merging (optional, after CI has been triggered) + - E.g. `linux-test`, `msrv`, and `lints` + - Require a merge queue using `squash and merge` (optional, only allowed if repo is public) + - Allow force pushes if needed to bypass above restrictions when necessary +- Enable full write access for Lurk Lab members by adding the `lurk-dev` team in `Settings->Collaborators and teams` +- Edit licenses and `deny.toml` as needed ## License