actions/superlint
1
0
Fork 0
mirror of https://github.com/super-linter/super-linter.git synced 2024-11-09 02:23:39 -05:00
Code Issues Projects Releases Packages Wiki Activity
superlint/.github/CONTRIBUTING.md
Lukas Gravley 57e0530d1b
cleaner (#2008) 
* cleaner

* fix bad name

* fix name

* adding flag

* fix links

* noise

* fix rules

* fix to warn

* remove textlint
2021-10-01 12:41:13 -05:00

3.3 KiB
Raw Blame History

Contributing

👋 Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.

Submitting a pull request

Pull Requests are used for adding new playbooks, roles, and documents to the repository, or editing the existing ones.

With write access

  1. Clone the repository (only if you have write access)
  2. Create a new branch: git checkout -b my-branch-name
  3. Make your change
  4. Push and submit a pull request
  5. Pat yourself on the back and wait for your pull request to be reviewed and merged.

Without write access

  1. Fork and clone the repository
  2. Create a new branch: git checkout -b my-branch-name
  3. Make your change
  4. Push to your fork and submit a pull request
  5. Pat your self on the back and wait for your pull request to be reviewed and merged.

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  • Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
  • Write good commit messages.

Draft pull requests are also welcome to get feedback early on, or if there is something blocking you.

  • Create a branch with a name that identifies the user and nature of the changes (similar to user/branch-purpose)
  • Open a pull request

CI/CT/CD

The Super-Linter has CI/CT/CD configured utilizing GitHub Actions.

  • When a branch is created and code is pushed, a GitHub Action is triggered for building the new Docker container with the new codebase
  • The Docker container is then ran against the test cases to validate all code sanity
    • .automation/test contains all test cases for each language that should be validated
  • These GitHub Actions utilize the Checks API and Protected Branches to help follow the SDLC
  • When the Pull Request is merged to master, the Super-Linter Docker container is then updated and deployed with the new codebase
    • Note: The branch's Docker container is also removed from DockerHub to cleanup after itself

Releasing

If you are the current maintainer of this action you can create releases from the Release page of the repository.

  • It will notify the issue it has seen the information and starts the Actions job
  • It will create a branch and update the actions.yml with the new version supplied to the issue
  • It will then create a PR with the updated code
  • It will then create the build the artifacts needed
  • it will then publish the release and merge the PR
  • A GitHub Action will Publish the Docker image to GitHub Package Registry once a Release is created
  • A GitHub Action will Publish the Docker image to Docker Hub once a Release is created

Resources