Skip to content

Mention composer ci and composer list in CONTRIBUTING.md #815

Open
@JakeQZ

Description

@JakeQZ

#807 removes contributor-related content from README.md. Most if it is now already covered in CONTRIBUTING.md. However, some nuances are not:

  • run composer ci to run all static and dynamic CI checks.

Details of other Composer scripts available (e.g. to run one specific CI check) are provided with composer list.

The guidelines currently only mention composer ci:tests:unit and composer ci:static, and do so in separate sections. Running both does presently amount to the equivalent of composer ci, but in future might not ecompass all that it does.

composer ci is particularly important to mention. If a proposed PR passes this, then it's likely the GitHub CI action checks will also pass, and the PR can be immediately reviewed. GitHub does not run the CI actions for PRs submitted by a non-collaborator until they are manually approved to be run (by a collaborator). This means a contributor does not get immediate feedback if there are some CI checks still failing. The eventual feedback they get will come via email and may be treated as spam. That may have been the case with #389.

Following on from that, it would perhaps also be helpful to outline the above in the contributing guidelines. And perhaps for collaborators to post a note to the PR if the checks fail after manual triggering - I have a feeling that emails for manual comments are routed differently to automated ones regarding CI failures; in any case, a hand-typed comment is less likely to be treated as spam.

Metadata

Metadata

Assignees

No one assigned

    Labels

    developer-specificIssues that only affect maintainers, contributors, and people submitting PRsdocumentation

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions