You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
prints "INFO: Running with: ./auter --prep Updates downloaded", /var/lib/auter/last-prep-auter
39
-
/var/lib/auter/last-prep-default contains update info
40
-
41
-
auter --apply
42
-
prints "INFO: Running with: /usr/bin/auter --apply; Applying updates; Updates complete, you may need to reboot for some updates to take effect
43
-
Run 'yum history info' or 'dnf history info' and verify that update was applied
44
-
/var/lib/auter/last-update-default contains update info
45
-
46
-
auter --reboot
47
-
prints "INFO: Running with: ./auter --reboot; Rebooting server" followed by shutdown message
48
-
tail /var/log/messages should include text "root: custom pre reboot script ran"
49
-
cat /etc/cron.d/auter-postreboot-auter should show "@reboot root /usr/bin/auter --postreboot --config auter"
50
-
5 mins after the reboot, tail /var/log/messages should include text "root: custom post reboot script ran"
36
+
1. Test the commands manually in a normal shell session.
37
+
2. Test for both positive and negative outcomes.
38
+
3. Test the effects of the change in the function. Again, if possible, test success and failure conditions
39
+
4. Test the all functionality in auter that is affected by they code changes.
40
+
41
+
##### Testing template
42
+
43
+
This should be completed in all pull requests before being merged.
44
+
45
+
```md
46
+
### Config settings
47
+
48
+
AUTOREBOOT="no"
49
+
ONLYINSTALLFROMPREP="yes"
50
+
PREDOWNLOADUPDATES=yes
51
+
52
+
### <OS test version>
53
+
54
+
#### auter status
55
+
56
+
[ pass/fail ] auter --status
57
+
- Check: /var/lib/auter/enabled exists
58
+
59
+
[ pass/fail ] auter --disable
60
+
- Check: /var/lib/auter/enabled does not exist
61
+
62
+
[ pass/fail ] auter --enable
63
+
- Check: /var/lib/auter/enabled exists
64
+
65
+
[ pass/fail ] auter --help
66
+
- Check: same output when running 'auter' without arguments
67
+
68
+
[ pass/fail ] auter --version
69
+
- Check: prints 'auter VERSION'
70
+
71
+
#### update manually
72
+
73
+
[ pass/fail ] auter --prep
74
+
- Check: prints "INFO: Running with: ./auter --prep Updates downloaded" to stdout
75
+
- Check: /var/lib/auter/last-prep-default contains update info
76
+
- Check: updates downloaded to /var/cache/auter/default
77
+
- Check: pre/post prep scripts ran successfully with messages logged to syslog
78
+
79
+
[ pass/fail ] auter --apply
80
+
- Check: prints "INFO: Running with: /usr/bin/auter --apply; Applying updates; Updates complete, you may need to reboot for some updates to take effect" to stdout
81
+
- Check: expected updates were applied using 'yum history info' or 'dnf history info'
82
+
- Check: /var/lib/auter/last-update-default contains update info
83
+
- Check: no upates available after running
84
+
- Check: pre/post apply scripts ran successfully, messages logged to syslog
85
+
- Check: no mail is sent to the root user with the stdout from auter
86
+
87
+
[ pass/fail ] auter --reboot
88
+
- Check: reboot scheduled in 2 minutes time
89
+
- Check: prints "INFO: Running with: ./auter --reboot; Rebooting server" followed by shutdown message to stdout
90
+
- Check: 5 minutes after reboot is complete pre/post reboot scripts ran successfully with messages logged to syslog
91
+
92
+
#### updates via cron
93
+
94
+
[ pass/fail ] auter --prep --stdout
95
+
- Check: updates downloaded to /var/cache/auter/default
96
+
- Check: pre/post prep scripts ran successfully, messages logged to syslog
97
+
- Check: output from auter also mailed to root user on CentOS boxes, output logged to syslog on Fedora systems
98
+
99
+
[ pass/fail ] auter --apply --stdout
100
+
- Check: no updates available after running
101
+
- Check: pre/post scripts ran successfully with messages logged to syslog
102
+
- Check: output from auter also mailed to root user on CentOS boxes, output logged to syslog on Fedora systems
103
+
104
+
[ pass/fail ] auter --reboot --stdout
105
+
- Check: server rebooted after 2 minutes
106
+
- Check: pre/post scripts ran successfully
107
+
- Check: output from auter also mailed to the root user on CentOS, output logged to syslog on Fedora
108
+
109
+
#### new functionality testing
110
+
111
+
[ pass/fail ] <test new functionality added>
112
+
- Check:
51
113
```
52
114
53
-
**Documentation**
115
+
#### Documentation
54
116
55
-
When making any changes to code, make sure documentation (--help, man page) has been updated to reflect any changes
117
+
When making any changes to code, make sure documentation (--help, man page) has been updated with the new functionality.
56
118
57
-
**Release Process**
119
+
#### Pull Request Rules
58
120
59
-
1. Ensure that all files are updated to the version of the release number you're about to tag. This includes:
60
-
- auter
61
-
- NEWS
62
-
- auter.spec
121
+
- All pull requests should be made against the develop branch
122
+
- All pull requests MUST be reviewed and approved before merging
123
+
- Pull request reviews and merges MUST be completed by another maintainer
124
+
- Always squash and merge commits prior to submitting a pull request
125
+
- All travis-ci tests should pass before merging
126
+
- If the spellcheck test fails, adding the problematic words to the dictionary is a valid option
127
+
- If the shellcheck test fails, you should fix the issues mentioned or add a shellcheck ignore directive to the previous line along with a comment on why it is being ignored
63
128
64
-
2. Add notes to auter.spec and NEWS with a list of the changes for this release
129
+
#### Release Process
65
130
66
-
3. Push to github
131
+
1. A new issue should be raised with the title of "Prep for <VERSION> Release"
132
+
2. Ensure all required PRs for the new release have been merged to the develop branch
133
+
3. A maintainer with admin rights to the master branch in rackerlabs/auter should create a new branch based from the develop branch:
5. Engage with the RPM building process to get RPMs built based on the new tag, and attach those to the github release.
142
+
4. Any new PRs should be made to the develop branch. The only changes to the Release-<NEW_VERSION> should be fixing of any review issues for that branch.
143
+
5. Full testing for all supported OSs should be carried out and tracked in a github project created for the release. Example: https://github.com/rackerlabs/auter/projects/1
144
+
6. Once all testing has been completed for Release-<NEW_VERSION>, the reviewer should merge the Release-<NEW_VERSION> branch to both master and develop branches.
145
+
7. Tag a new release named <NEW_VERSION> using template <majorver>.<minorver> (Eg: Release 0.11)
Copy file name to clipboardexpand all lines: README.md
+6
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,12 @@
2
2
3
3
Automatic updates for RHEL, CentOS, Fedora, Ubuntu and Debian Linux servers, with the ability to run pre/post hooks, pre-download packages and reboot after the updates.
4
4
5
+
**Note about contributions**
6
+
Auter is an open source project and we welcome users to send in feature requests and report any bugs in our issues page. We also welcome any help with maintaining the application and any code contributions.
7
+
8
+
**What does auter mean?**
9
+
Automatic Update Transaction Execution by Rackspace.
10
+
5
11
**When to use Auter?**
6
12
7
13
Updates should be applied regularly to Linux systems in order to apply security and bug fixes. For some of those updates, for example the kernel, or a shared library, a system restart is required for those updates to take effect. Whether you apply those updates manually, or automatically will depend on your requirements.
0 commit comments