-
Notifications
You must be signed in to change notification settings - Fork 1
Workflow
- Table of Contents
- Fixing a bug or an issue in a role
- Triaging an issue
- Fixing an issue
- List of labels
- Enhance a role
The title should describe the issue, not the expected result, for example, "the role does not support X", not "Support X". It should be what it should be, not what should be done. A bad example is, "Support platform X" and a good example is, "The role does not support platform X".
The comment body should describe:
- the issue in detail
- the expected result
- a possible action to be taken
- the version of role, ansible, and OS, when relevant
- include the way to reproduce the issue, if any
Choose lables and add them to the issue. See the list of labels below and when to assign which.
If there is a planned milestone, such as the next release, consider assigning the issue to it.
If you are going to fix the issue yourself, assign your account. If you do not know how to fix it or are unable to fix it, leave it empty
When an issue is created, decide what to do with it. If the issue cannot be
fixed soon, add pending label to the issue and leave a comment on why. If the
issue can be fixed, assign the issue to a sysadmin.
Unassigned issues are reviewed and discussed on weekly basis. See FIXME.
When you are going to fix an issue, open the issue and assign yourself if nobody is assigned. If someone has been assigned to the issue, discuss with the assignee.
Merge the master branch into your local master branch. Before git pull
make sure that the default action of pull is rebase.
git config --global pull.rebase true
git checkout master
git pull
Create a branch for the issue. The branch name should be "issue-$NUMBER". If the branch will include mutiple fixes for issues, create a discriptive branch name.
git checkout -b issue-$NUMBER
Fix the issue in your local repository. Make sure unit tests and integration tests, if any, pass on your local machine.
When all tests pass, push the branch.
git push --set-upstream origin issue-$NUMBER
Make sure all the tests pass in github. Broken branch or untested branch must not be merged.
| Name | Description | Examples |
|---|---|---|
| bug | Bugs, regressions, and something the role should do but does not | Undocumented variables, broke build |
| duplicate | The issue is a duplicate of other issues | N/A |
| enhancement | The issue enhances the role, such as adding supported platforms, implementing new feature | Supporting new platform, adding new functionality |
| invalid | The issue cannot be reproduced, it cannot be fixed, or it is not an issue of the role | Issues caused by mis-configuration |
| risk treatment | The issue is implied by risk treatment results, which must be implemented | Issues mentioned in risk treatment plan |
| pending | The issue cannot be resolved but will be | The issue is blocked by some other issues |
When an option value contains %, ssh(1) expands the percent and a following
character as a macro, explained in ssh_config(5). To escape %, as in our
case, you need to replace % with %%. However, -i flag has a bug. Given
-i /path/%%to%%/key, meaning your key is located at /path/%to%/key, ssh(1)
says it does not exist. Given -i /path/%to%/key, it tries to expand it but
does not know about %t, resulting to an error. Thus, ansible play fails.
Use -o IdentityFile /path/%%to%%/key, which replaces %% with %, instead
of -i.
The
diff
solves the issue. You need to apply the patch to vagrant on Jenkins.