Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated contribution guidelines #83

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions contribute.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,21 +5,23 @@ Thank you for considering contributing to our project! We welcome contributions

## Issue Tracking

Please check our [issue tracker](https://github.com/AlabamaWaterInstitute/CloudInfra/issues) for existing issues that you can work on. If you find a new issue or have a feature request, please open a new issue so we can discuss it and prioritize it accordingly.
Please check our [issue tracker](https://github.com/CIROH-UA/NGIAB-CloudInfra/issues) for existing issues that you can work on. If you find a new issue or have a feature request, please open a new issue so we can discuss it and prioritize it accordingly.


## How to Contribute

1. If an Issue does not already exist, you can use the [bug report template](https://github.com/CIROH-UA/NGIAB-CloudInfra/issues/new?assignees=&labels=bug&projects=&template=bug_report.md&title=) to create one.

1. Fork the repository and clone it to your local machine.

2. Create a new branch for your changes using the format "feature/`<feature-name>`" or "bugfix/`<bug-name>`".
2. Click on the “Create a branch” button to create a new branch. Choose the automatically selected branch.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is anyone allowed to actually create branches on the repo?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hellkite500 Are you able to create a branch on the repo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For us internally we should be able to create branch in this repo. But for outside colloborators, we will have to find a fix for the PR validation using forked branch.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can, but I'm an invited collaborator. Also, the directions for "Create a branch" are not clear. I checked to see if there was an obvious "Create a branch" button, and didn't see one.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that the elements in #53 may help this problem -- splitting the build and the push steps into different workflows that can be run independently (or together, if needed) will give more flexibility with testing purposed changes to the IaC components, while reserving the release (the push action which requires the dockerhub login) to be reserved for triggers such as "merged to main" which happen after review and approval and should be be able to use the internal secrets.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can, but I'm an invited collaborator. Also, the directions for "Create a branch" are not clear. I checked to see if there was an obvious "Create a branch" button, and didn't see one.

Once you submit the Issue, you will see option of "Create a branch" under Development section on right side section.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that the elements in #53 may help this problem -- splitting the build and the push steps into different workflows that can be run independently (or together, if needed) will give more flexibility with testing purposed changes to the IaC components, while reserving the release (the push action which requires the dockerhub login) to be reserved for triggers such as "merged to main" which happen after review and approval and should be be able to use the internal secrets.

Yea thank you Nels for this suggestion. @benlee0423 if you could please take a look at #53 and try it on your end to split the build and push steps into different workflows as suggested by Nels. We can discuss once you take alook.


3. Make your changes and commit them with clear and concise commit messages.

4. Push your changes to your forked repository.
4. Push your changes to the branch.

5. Open a pull request from your branch to the repository with a clear and descriptive title and detailed description of your changes.

5. Open a pull request from your forked repository to our repository with a clear and descriptive title and detailed description of your changes.
6. Once your pull request is submitted, a PR validation CI pipeline will trigger that will validate the changes.

6. Once your pull request is submitted, it will be reviewed by the maintainers. You may be asked to make further changes before your contribution can be merged.
7. Please make sure that the PR pipeline is successful.

8. The maintainers of the repository will merge the PR upon successful CI workflow.
Loading