github.com/SUSE/skuba@v1.4.17/CONTRIBUTING.md (about) 1 # Contributing to skuba 2 3 The following is a set of guidelines for contributing to this project, hosted by [SUSE](https://github.com/suse/skuba). 4 If you have a suggestion to these guidelines feel free to propose changes in a pull request. 5 6 7 ## Pull requests 8 9 Contributors: 10 * Adhere to the PR template. Fill out as many sections as possible with as much detail as possible. 11 * Adhere to the style guide as closely as possible, where a bot cannot do it for you. 12 * The PR is ready for review only when the CI is green. Do not ask for people to review your code if the CI is failing. 13 * If CI is not passing, or you need to make more improvements than expected, please add the wip label. 14 * Once the CI is green, feel free to assign specific reviewers to your PR to signal it is ready. 15 * Do NOT merge pull requests. CI will automatically merge the PR once tests pass and approvals are received. 16 17 Maintainers: 18 * Devote time to regular code review and make your reviews impactful. Look at the big picture, don't get hung up on style alone. 19 * Veto only when there's is something really problematic, otherwise just comment. Otherwise you are forcing a new round of reviews including a new CI run. 20 * Add yourself to the [CODEOWNERS](.github/CODEOWNERS) file if you want to be assigned automatically as reviewer in a particular area. 21 22 23 ## Styleguides 24 25 ### git commit messages 26 27 This list is not comprehensive, meaning if you want to include more detail than required that is fine as long as you meet these guidelines first. 28 29 * Title 30 * Always start with an upper-case letter 31 * Do not put a dot (period) at the end 32 * Use imperative verbs 33 * Maximum characters: 50 (excluding the (bsc#123456) part) 34 * Tracking issues from Bugzilla 35 * Add `(bsc#123456)` as part of the title 36 37 * Body 38 * Start sentences with upper-case letter and finish with dot (period). 39 * Maximum characters per line is 72 40 * Explain what this commit is doing 41 * Explain why we have to do it 42 * Do not explain how unless the change is sufficiently large and needs further explanation 43 * Tracking issues from Github: 44 * __Do not track references (ID/URLs) to in the commit message__ but on the web-ui (yes you are forced to open your browser) 45 46 ## Go style 47 48 This will be checked automatically by our CI linter bot. 49 50 ## Releasing 51 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 53 + If you are releasing a new kubernetes version, or any other container, + 54 + make sure the versions.go has been updated accordingly. See as an + 55 + example: + 56 + https://github.com/SUSE/skuba/pull/573 + 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 58 59 In order to create a new release, perform the following steps: 60 61 * Create a tag: 62 * Tag with `vX.Y.Z`: `git tag -s vX.Y.Z -m "Tag X.Y.Z" <commit>` 63 * Allowed tag format: 64 * `vX.Y.Z-alphaN?`: creates an alpha release (e.g. `v1.0.0-alpha`, 65 `v1.0.0-alpha3`) 66 * `vX.Y.Z-betaN?`: creates a beta release (e.g. `v1.0.0-beta`, 67 `v1.0.0-beta1`) 68 * `vX.Y.Z-rcN?`: creates a release candidate (e.g. `v1.0.0-rc`, 69 `v1.0.0-rc2`) 70 * `vX.Y.Z`: creates a final release 71 * `<commit>` argument can be omitted if you want the tag to point to `HEAD` 72 73 * Push the tag: `git push <remote> vX.Y.Z` 74 * Note: `<remote>` should be pointing to the 75 `github.com/SUSE/skuba` repository 76 77 * Checkout the tag: `git checkout vX.Y.Z` 78 79 * Create the changelog: `make suse-package` 80 81 * Add a new release at https://github.com/SUSE/skuba/releases with the contents from the file `ci/packaging/suse/obs_files/skuba.changes.append` 82 83 * Use the files in `ci/packaging/suse/obs_files` to update the skuba package