Updated contribution guidelines #83
Conversation
arpita0911patel
requested review from
hellkite500,
ZacharyWills and
benlee0423
| 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. |
There was a problem hiding this comment.
Is anyone allowed to actually create branches on the repo?
There was a problem hiding this comment.
@hellkite500 Are you able to create a branch on the repo?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Nels <[email protected]>
Co-authored-by: Nels <[email protected]>
benlee0423
deleted the
81-update-the-issue-tracker-link-in-the-contribute-markdown-file
branch
No description provided.