Skip to content
This repository has been archived by the owner on Jun 13, 2024. It is now read-only.

Latest commit

 

History

History
201 lines (141 loc) · 6.54 KB

CONTRIBUTING.md

File metadata and controls

201 lines (141 loc) · 6.54 KB

Contributing

Thank you for considering to contribute to the CircleCI Visual Config Editor! Before you get started, we recommend taking a look at the guidelines belowL

Have a Question?

Have a question about the CircleCI or the Visual Config Editor?

I have a general question about CircleCI or CircleCI's config.yml file.

Contact CircleCI's general support by filing a ticket here: Submit a request

I have a question about JavaScript or best practices

Share your question with CircleCI's community Discuss forum.

I have a question about the Visual Configuration Editor

You can always open a new issue on the repository on GitHub.

Discover a Bug?

Find an issue or bug?

You can help us resolve the issue by submitting an issue on our GitHub repository.

Up for a challenge? If you think you can fix the issue, consider sending in a Pull Request.

Missing Feature?

Is anything missing?

You can request a new feature by submitting an issue to our GitHub repository, utilizing the Feature Request template.

If you would like to instead contribute a pull request, please follow the Submission Guidelines

Contributing

Thank you for contributing to the CircleCI Visual Config Editor!

Before submitting any new Issue or Pull Request, search our repository for any existing or previous related submissions.

Submission Guidelines

Commit Conventions

This project strictly adheres to the conventional commits specification for creating human readable commit messages with appropriate automation capabilities, such as changelog generation.

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(optional <scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Footer should contain a closing reference to an issue if any.

Breaking Change

Append a ! to the end of the type in your commit message to suggest a BREAKING CHANGE

<type>!(optional <scope>): <subject>
Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: npm, eslint, prettier)
  • ci: Changes to our CircleCI configuration
  • chore: No production code changes. Updates to readmes and meta documents
  • docs: Changes to the automated documentation or TSDoc comments
  • feat: A new feature
  • fix: A bug fix
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • sample: A change to the samples
Scope

Scopes should be limited to the following list:

  • ClassName: The name of the TS class being modified or tested
  • sample/#: The number of the sample added or modified
  • pkg: Anything related to modifying the package.json

Submitting a Pull Request

After searching for potentially existing pull requests or issues in progress, if none are found, please open a new issue describing your intended changes and stating your intention to work on the issue.

Creating issues helps us plan our next release and prevents folks from duplicating work.

After the issue has been created, follow these steps to create a Pull Request.

  1. Fork the CircleCI-Public/visual-config-editor repo.
  2. Clone your newly forked repository to your local machine.
  3. Create a new branch for your changes: git checkout -b fix_my_issue main
  4. Implement your change with appropriate test coverage.
  5. Utilize our commit message conventions.
  6. Run tests, linters, and formatters locally:
    • npm run test
    • npm run prettier
    • npm run lint
  7. Push all changes back to GitHub git push origin fix_my_issue
  8. In GitHub, send a Pull Request to visual-config-editor:main

Thank you for your contribution!

After Your PR Has Been Merged

After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:

  • Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:

    git push origin --delete fix_my_issue
  • Check out the main branch:

    git checkout main -f
  • Delete the local branch:

    git branch -D fix_my_issue
  • Update your main with the latest upstream version:

    git pull --ff upstream main

How To Issue a Release

For maintainers only

This is subject to change

This project is managed using GitHub Project Boards and is released on NPM automatically after manually creating a GitHub tag and release.

When it is time to release a new version of this package, follow the following steps.

  1. Ensure all relevant PRs have been merged into the main branch, awaiting "deployment".
  2. Review the commit history to determine the release type (major, minor, patch)
  3. Update the package.json file with the new version tag.
  4. On GitHub, create a new Release with the main branch as the target and specify the version number.
  5. Include the commit bodies from git log for the included commits.