Skip to content

Maintenance Request GitHub Pull Request

Kseniya Shychko edited this page Feb 13, 2024 · 2 revisions

If you would like you can also create a GitHub Pull Request related to your Maintenance Request.

Edit the current version of the code list in csv format under 'current' directory - add new records, update name or description for existing ones, mark some as deleted or reinstate the previously deleted ones.

image

You can always preview the changes before commiting them:

image

Click on Commit changes ..., provide a commit message and choose the option Create a new branch for this commit and start a pull request

image

The new branch will be created with you commit and you will be brought to Open a pull request page:

image

Make sure to leave only the related code list and assign the right lables, it will speed up the review process. Reference the related GitHub issue(s) that describe(s) the requested updates to the code list:

image

Click on Create pull request: image

Once the pull request is created a validation worflow is triggered. It performs some basic validation like cheking the the status or change indicator is set properly, that there are no duplicates ore removed records, that the file itself hasn't been accidentally deleted or renamed.

If all is OK the validation process will add a comment to your PR with a diff summary of your changes - which records were added or updated.

image

If not, the status check will fail for your commit and PR merge will blocked until validation passes. A comment with details about what caused validation failure is added to the PR when it's possible:

image

In addition to the required status check your pull request requires at leaset one approved review and review from the code owners:

image

During review process the reviewer can leave comments and propose suggestions on how to fix the PR - that's really helpful as those suggestions are clear instructions how to fix the problem, easy to add and easy to apply.

image

Another requirment - the branch needs to be up-to-date to be allowed to merged in. It guarantees that no changes will accidentaly clash or overwite one another. The history of a code list changes is linear and easy to read. image

When the changes are approved and merged into main branch, another job is triggered that deploys them to https://test.uncefact.org/vocabulary/vocab-codes for review. It just takes a couple of minutes to update it.

Clone this wiki locally