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 about the CircleCI or the Visual Config Editor?
Contact CircleCI's general support by filing a ticket here: Submit a request
Share your question with CircleCI's community Discuss forum.
You can always open a new issue on the repository on GitHub.
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.
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
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.
This project strictly adheres to the conventional commits specification for creating human readable commit messages with appropriate automation capabilities, such as changelog generation.
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.
Append a !
to the end of the type
in your commit message to suggest a
BREAKING CHANGE
<type>!(optional <scope>): <subject>
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
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
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.
- Fork the CircleCI-Public/visual-config-editor repo.
- Clone your newly forked repository to your local machine.
- Create a new branch for your changes:
git checkout -b fix_my_issue main
- Implement your change with appropriate test coverage.
- Utilize our commit message conventions.
- Run tests, linters, and formatters locally:
npm run test
npm run prettier
npm run lint
- Push all changes back to GitHub
git push origin fix_my_issue
- In GitHub, send a Pull Request to
visual-config-editor:main
Thank you for your contribution!
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
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.
- Ensure all relevant PRs have been merged into the
main
branch, awaiting "deployment". - Review the commit history to determine the release type (major, minor, patch)
- Update the
package.json
file with the new version tag. - On GitHub,
create a new Release
with the
main
branch as the target and specify the version number. - Include the commit bodies from
git log
for the included commits.