andrewvaughan / template-core Goto Github PK

Description

With any automation efforts:

1. Create a Kanban project for the project for all issues
2. Remove Status labels and transfer them to Project statuses
3. Ensure all new issues automatically enter the Pending (or similar) state in the Kanban project
4. Update all documentation that refer to statuses and labels to refer to the project (especially Contributing Guidelines)
5. Update the Template Checklist to set up a project, if it can't be done automatically
6. By default set all new issues to be part of the project
7. Move issue priority to a project variable
8. Remove janky automation of labels Issues if Project can handle it for us

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Scope(s)

No response

New or Existing Documentation

Existing Documentation

Description

It's hard to read right now. Simplify and use short sentences.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add a default helper to makefile. Look at https://github.com/oxsecurity/megalinter for inspiration.

Description

Issue templates currently don't enforce the optional part of the checkbox from the GitHub example - may be a problem with GitHub, given it's directly from their documentation.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add Status: Stale label to any open issues with no activity in 30-days unless one of these labels is already on the issue:

• Help Wanted
• Needs Triage
• Status: On Hold
• Status: Stale (ignore anything already marked)
• Status: 06-Released

Auto-close issues that have been marked Status: Stale and have not had activity in 60-days, unless it was opened by a project maintainer with a message to the issue as to why it was closed.

The following logic items should be implemented:

Issue created

• Add the Needs Triage label
• Add the appropriate Request: ... label

Issue has a user assigned

• Remove the Help Wanted label
• Add a warning if the Needs Triage label still exists
• Add a warning if Issue status is one of No Status, Done, or Parking Lot statuses
• If in the Approved for Development project status, move it to In Progress

Issue has a user unassigned

(All steps below are triggered only if there are no more assignees on the Issue)

• Add the Help Wanted label
• If in the In Progress project status, revert to Approved for Development and add a notice to the Issue
• If in the Code Review project status, revert to the Approved for Development and add a notice to both the Issue and the Pull Request
• Add a warning if the Issue status is one of Pending Deployment, User Acceptance Testing, or Done

Issue has a milestone assigned

• Remove the Needs Release Assignment label
• If assignment occurs in the No Status or Parking Lot statuses, add a warning

Issue has a milestone unassigned

• Add the Needs Release Assignment label
• If assignment occurs in the In Progress, Code Review, Pending Deployment, User Acceptance Testing, or Done` statuses, add a warning

Branch is created in ref format ***/####/***

• If issue #### is in status Approved for Development move to In Progress
• If issue #### is in status No Status or Parking Lot add warning about working on unapproved effort
• If issue #### is in status In Progress, Code Review, Pending Deployment, or User Acceptance Testing add warning about duplicative effort
• If issue #### is in status Done add warning about working on completed effort

Branch in deleted in ref format ***/####/***

• If Issue #### is status In Progress or Code Review, move Issue to status Approved for Development and add a warning to the Issue

Make sure that auto-branch deletion happens before this logic is performed or Code Review warnings will occur when PRs are accepted

Pull Request is created

• Scan all added commit messages for (closes #...) and move Issues to status Code Review
• If more than one (closes #...) message is found, add a warning to the Pull Request that multiple Issues are attached
• If no (closes #...) messages are found in the Branch, add a warning to the Pull Request that no Issues are attached

Pull Request is updated

• Scan all added commit messages for (closes #...) and move Issues to status Code Review
• If possible, figure out if any (closes #...) were removed from prior commit messages and revert those Issues to In Progress
• If more than one (closes #...) message is now found, add a warning to the Pull Request that multiple Issues are attached
• If no (closes #...) messages are now found in the Branch, add a warning to the Pull Request that no Issues are attached

Pull Request is accepted

See various branch merge tasks, below.

Pull Request is canceled

• Scan all added commit messages for (closes #...) and move Issues to status In Progress with warning
• Add warning to Pull Request listing all Issues that were reverted to In Progress

main branch is updated via merge

• Scan all added commit messages for (closes #...) and move Issues to status Pending Deployment

main branch is updated via force push or rolled back

• Review diff of prior main and new main and update Issues accordingly
  • Any commit messages with (closes #...) that...
    • ...were removed, add a warning to the Issue and place the Issue to status In Progress and add label Needs Triage
    • ...remain that aren't User Acceptance Testing or Done move to Pending Deployment with a warning
    • ...remain that are User Acceptance Testing or Done add a warning about a main rollback on a furthered status

staging branch is updated via merge

• Scan all added commit messages for (closes #...) and move Issues to status User Acceptance Testing

staging branch is updated via force push or rolled back

• Review diff of prior staging and new staging and update Issues accordingly
  • Any commit messages with (closes #...) that...
    • ...were removed, add a warning to the Issue and place the Issue to status In Progress and add label Needs Triage
    • ...remain that aren't Done move to User Acceptance Testing with a warning
    • ...remain that are Done add a warning about a staging rollback on a furthered status

production branch is updated via merge

• Scan all added commit messages for (closes #...) and move Issues to status Done

production branch is updated via force push or rolled back

• Review diff of prior production and new production and update Issues accordingly
  • Any commit messages with (closes #...) that...
    • ...were removed, add a warning to the Issue and place the Issue to status In Progress and add label Needs Triage
    • ...remain move to Done with a warning

Add code-coverage analysis and minimums to the workflow. Add README instructions for how to customize this.

Add a CODEOWNERS file where the default goes to me.

Scopes

No response

New or existing documentation

Existing documentation

Description

https://github.com/andrewvaughan/template-core/workflows/MegaLinter/badge.svg

https://github.com/andrewvaughan/template-core/workflows/MegaLinter/badge.svg?branch=main

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add configuration files and workflows for label-sync to keep in sync with this repository:
https://github.com/marketplace/actions/label-sync

Description

Without tons of custom dictionaries, add Makefile linting support for CSpell and Vale.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Due to a bug in Megalinter, Lychee configurations must be in the project root. When this issue is fixed, these configurations need to be moved back to the .config/linters folder.

When all documentation is complete - read through everything and ensure:

• Grammar and 3rd person is consistent
• It reads well
• It's formatted correctly

Ensure a prose writer performs a check, as well.

Any changes and cleanup should be applied to this issue, or it can be closed directly if no work is needed.

Change a reference for commit requirements in contributing to:
https://developercertificate.org/

Description

As much as possible, move linting from JSON to YML to allow for better in-document commenting.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add a Makefile folder group with the following skeleton items:

• all
• test
• test-lint (to call Megalinter locally)
• test-bdd (and create a GitHub workflow file that runs this for PRs)

Description

Right now, only push end-to-end testing occurs on production and staging. This actually doesn't work as intended:

1. Any time a pull_request is made to staging or production
2. Any time a push occurs to main, staging, or production

This way, badges always represent full end-to-end tests, but pull requests can be more efficient for main. Pull requests for environments still should be end-to-end, however, to give reviewers a comprehensive overview of what to expect in the environment.

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

If a Pull Request drops reference to an issue, it can likely sit in a Code Review status indefinitely, as there's no way to warn the issue maintainer that the issue was dropped.

Any issues In Progress or beyond that don't change state should get a warning after 30-days and a Stale label.

Add badge to README

Description

Vale had a pretty cool looking license - I'm curious if this might be an option:

https://github.com/errata-ai/vale?tab=readme-ov-file#page_facing_up-license

Here's the Fossa dashboard:

https://app.fossa.com/projects/custom%2B21090%2Fgithub.com%2Ferrata-ai%2Fvale/refs/branch/v2/e3b296254dccf8e7946b694cd34d0c1fa18aadc6/preview

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add standard security instructions for all projects.

Description

Instead of using status labels for priority and status, create a Kanban project. Make sure to update the documentation (including template checklists) regarding the changes.

If possible, automate the creation and workflow rules for changes made to Issues based on project state.

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add tests in integration testing that check that

• Commit message titles are fewer than 50 characters (warning) and 72 characters (error)
• Commit message follows standard form (Type: Description (closes #..) (warning)
• If type is provided, it is a valid type (warning)
• Body exists (warning)
• Title and body are separated by a blank line (error, if exists)
• Body is wrapped to 72 characters (error, if exists)

Description

Look into why Require branches to be up to date before merging in rulesets isn't finding megalinter and update the template checklist to have this checked once fixed.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Description

Replace manual rules in _TEMPLATE_CHECKLIST.md with imports, now that ruleset export/import are supported.

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Description

Uncomment configurations and code linting in Vale. Disabled due to issues with TokenIgnore/etc.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add SUPPORT.md to direct GitHub users how to request support.

Configure dependabot and add instructions to the README on how to customize it; ensure it automatically creates Pull Requests for updates and vulnerabilities.

Add Megalinter, defaulting to "full" flavor. Instruct in README to adjust this to match the flavor most-appropriate for the project and to modify the configuration file(s) appropriately.

This can't be done until act fixes their issue with job management:

nektos/act#1993

Research a static code analysis workflow that can look at code changes for risks and performance.

Add workflow to carry over default settings, including:

• Repository settings
• Rulesets
  • Branch rules
  • Tag naming restrictions
• Labels (handled in #1)

See if the Docker layers can be cached to speed up action execution. Cache is limited to 10GB.

• https://docs.docker.com/build/cache/backends/gha/
• https://docs.docker.com/build/cache/
• https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

Megalinter is a great candidate, with the "basic" unflavored version taking over 2 minutes to pull each run.

Add a skeleton README file with instructions on steps to follow after cloning the template as well as instructions on how to use various workflows (e.g., label-sync).

Incorporate a simple banner (to make it easier for the project if they wish to use one) and the following badges:

• Release | vX.X.X
• License | TK
• Build | passing/failing
• Coverage | %

Skeleton should contain the following sections:

• Header
• Installation
  • Developer Installation
  • Dependencies
• Usage
• Contributing
  • Testing
• Release Policy
• License

https://github.com/release-drafter/release-drafter

Per SchemaStore/schemastore#3301 the GitHub issue schema is outdated and causing failures. There currently is an exclusion for the in-scope files in the .mega-linter.yml root configuration that will need to be removed when this is resolved.

Description

GitHub had a huge oversight when disabling Classic Projects and not supporting V2 Projects in GitHub Actions. As such, these automations could not be implemented and must be done manually during the SDLC. These should be added when and if GitHub finally gets around to meeting their established functionality with V1 projects.

This is an extension from Issue #23, so that other automation functionality would not be blocked.

Relevant references:

• https://github.com/orgs/community/discussions/17405#discussioncomment-2940411
• https://github.com/orgs/community/discussions/84050 (Projects community)
• https://github.com/orgs/community/discussions/62113 (Actions community)

Although GitHub seems to not be interacting with the community much, I don't expect this to be fixed any time soon...

Issue moves to Approved for Development

• Remove the Needs Triage label
• Add the Help Wanted label, if no user assigned
• Add the Needs Release Assignment label, if no milestone set
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• If a Wontfix label is on the Issue, add a warning comment

Issue moves to In Progress

• Remove the Needs Triage label
• Add the Help Wanted label and a warning, if no user assigned
• Add the Needs Release Assignment label and a warning, if no milestone assigned
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• Add a warning if a Wontfix: ... label exists
• Add a warning if no Project Points or Priority are set

Issue moves to Code Review

• Remove the Needs Triage label
• Add the Help Wanted label and a warning, if no user assigned
• Add the Needs Release Assignment label and a warning, if no milestone assigned
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• Add a warning if a Wontfix: ... label exists
• Add a warning if no Project Points or Priority are set
• If moved via the board (i.e., not a Pull Request) add a warning about needing a PR

Issue moves to Pending Deployment

• Remove the Needs Triage label
• Add the Help Wanted label and a warning, if no user assigned
• Add the Needs Release Assignment label and a warning, if no milestone assigned
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• Add a warning if a Wontfix: ... label exists
• Add a warning if no Project Points or Priority are set
• If moved via the board (i.e., not a main Pull Request acceptance) add a warning about needing a PR

Issue moves to User Acceptance Testing

• Remove the Needs Triage label
• Add the Help Wanted label and a warning, if no user assigned
• Add the Needs Release Assignment label and a warning, if no milestone assigned
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• Add a warning if a Wontfix: ... label exists
• Add a warning if no Project Points or Priority are set
• If moved via the board (i.e., not a staging Pull Request acceptance) add a warning about needing a PR

Issue moves to Done

• Remove the Needs Triage label
• Add the Help Wanted label and a warning, if no user assigned
• Add the Needs Release Assignment label and a warning, if no milestone assigned
• Transition the Request: ... label to the appropriate Type: ... label
• Add a warning if no Request: ... or Type: ... label exists
• Add a warning if a Wontfix: ... label exists
• Add a warning if no Project Points or Priority are set
• If moved via the board (i.e., not a production Pull Request acceptance) add a warning about needing a PR

Issue moves to Parking Lot

• Remove the Needs Triage label
• Remove the Help Wanted label
• Remove any assigned user
• Remove any assigned milestone
• If a Pull Request with this Issue engaged is open, add a warning

Examples

No response

Priority

None

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add standard contributing guidelines that dictate branch structure, squash merging, pull request requirements, testing requirements, etc.

Add a README note to check the directions for testing as-appropriate for the project.

Also add a generic CONTRIBUTORS file with me as the only contributor.

Add an .editorconfig file that defaults for common file types.

Scope(s)

Other

New or Existing Documentation

New Documentation

Description

Add a style guide for palette, typography, logo, etc for Chiberia Projects.

Adding a template SCSS file may be helpful, as well.

Example(s)

No response

Priority

Moderate (Similar to most work being done today)

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Issues:

• Bug Report
• Feature Request
• Support Request
• Security Incident

Update the various markdown documentation files that refer to these for links.

Description

Vale, CSpell, etc are not currently configured well within the workspace and throw a ton of spelling and prose errors on code.

First, it should be attempted to have code be ignored in these editors (which may require some research for code types that are not natively supported - like Makefiles). Second, those files should be ignored, if necessary (but this isn't a great solution, since future projects may add code files that have this problem).

It'd definitely be better to show an example of how to support a code file than ignore it and miss out on comment linting.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add these files to the repository, as well as instructions in the README file as to which one to select:

Permissions

As described by:

Conditions

As described by:

Limitations

As described by:

Reference: https://choosealicense.com/

Description

For some reason, TODO entries in text files, etc aren't counted in the VSCode extension used. Some files will highlight code, but not show in the checklist when scanning the Workspace. Other files (like .txt) won't count it at all, which I believe is a feature to avoid counting documentation. See if there's a way to include this for files like the Vale and CSpell dictionaries.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add a standard COC for all projects.

Add these folders and ensure this table is in the README to instruct users how to use them:

Description

Require a period at the end of every sentence in comments/etc if possible. This likely will require a custom Style in Vale.

Example(s)

No response

Priority

None

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Add a workflow that can be triggered to create the default issues instructing steps to follow after the template has been copied. Add instructions to the README to run this workflow immediately after copying the template.

This should replace the checklist in the README.