Maintainer Guide

This is a guide for buildtest maintainers

Incoming Pull Request

These are just a few points to consider when dealing with incoming pull requests

  1. Any incoming Pull Request should be assigned to one or more maintainers for review.

  2. Upon approval, the PR should be Create a merge commit or Squash and merge depending on your preference. To preserve commit history please use Create a merge commit though sometimes it can be useful to do Squash commit. For more details on merge request see https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request

  3. Maintainers can request user to put meaningful commit if author has not provided a meaningful message (i.e git commit --amend)

  4. Maintainers are requested that committer name and email is from a valid Github account. If not please request the committer to fix the author name and email.

  5. All incoming PRs should be pushed to devel branch, if you see any PR sent to any other branch please inform code owner to fix it

Release Process

Every buildtest release will be tagged with a version number using format X.Y.Z. Every release will have a tag that corresponds to a release such as v1.2.3. Git tags should be pushed to upstream by release manager only. The process for pushing git tags can be described in the following article: Git Basics - Tagging

We will create annotated tags as follows:

git tag -a v1.2.3 -m "buildtest version 1.2.3"

Once tag is created you can view the tag details by running either:

git tag
git show v1.2.3

We have created the tag locally, next we must push the tag to the upstream repo by doing the following:

git push origin v.1.2.3

Every release must have a release note that is maintained in file CHANGELOG.rst

Under buildtest releases a new release can be created that corresponds to the git tag. In the release summary, just direct with a message stating refer to CHANGELOG.rst for more details

Once the release is published, make sure to open a pull request from devel –> master and Rebase and Merge to master branch. If there are conflicts during merge for any reason, then simply remove master and create a master branch from devel.

Default Branch

The default branch is devel and this should be protected branch.

Branch Settings

All maintainers are encouraged to view branch settings for devel and master. The master and devel branches should be protected branches and devel branch should be set as the default branch. Shown below is the expected configuration.

../_images/buildtest_branch_settings.png

If something is not correct please consult with the maintainers.

Merge Settings

We have enabled all commit types i.e (merge commits, squash merging, rebase merging) for merging Pull Request. Shown below is the recommended configuration, if you see a deviation please inform the maintainers.

../_images/buildtest_merge_options.png

If you notice a deviation, please consult with the maintainers.

Google Analytics

The buildtest site is tracked via Google Analytics, if you are interested in get access contact Shahzeb Siddiqui @shahzebsiddiqui

Read The Docs Access

buildtest project for readthedocs can be found at https://readthedocs.org/projects/buildtest/. If you need to administer project configuration, please contact Shahzeb Siddiqui @shahzebsiddiqui to gain access.

Slack Admin Access

If you need admin access to Slack Channel please contact Shahzeb Siddiqui @shahzebsiddiqui. The slack admin link is https://hpcbuildtest.slack.com/admin