android / android/nowinandroid
[FR]: Document the dependency update process
- Dominant language
- Kotlin
- Stars
- 21.8k
- Forks
- 4.6k
- Avg merge
- 19h 20m
- Merged PRs (30d)
- 2
Description
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Describe the problem
Now that we have enabled first party support for dependency updates https://github.com/android/nowinandroid/pull/893, we should also go the extra mile to ensure a smooth and timely update process.
Pending dependabot updates are listed here:
- https://github.com/android/nowinandroid/labels/version%20update
- https://github.com/android/nowinandroid/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+author%3Aapp%2Fdependabot
### Describe the solution
1. Duplicating reviews and pinging maintainers is probably not a good solution...
2. The simpler solution would be to give review/write permission to more maintainers, but I understand that this could be difficult to set up, with legal concerns.
3. An alternative could be to implement an automated update process to approve and merge patch/minor updates when the build succeeds. This can be implemented with a custom workflow [like this one](https://github.com/SimonMarquis/TIL/blob/main/.github/workflows/dependabot-auto-merge.yml) (as documented [here](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#enable-auto-merge-on-a-pull-request)).
### Additional context
We might also document the chosen solution (process, implications, etc.) in the main [README.md](https://github.com/android/nowinandroid/blob/main/README.md) for everyone to read.
### Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Contributor guide
Research direction
Start by reviewing the dependency-update support in PR #893, the pending Dependabot update links, and the linked GitHub Actions workflow example. Decide which update process is selected, then document that process and its implications in README.md; completion means the chosen approach is clear for maintainers and contributors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- devops, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100