android / android/nowinandroid

[FR]: Document the dependency update process

Open
#1,083 0 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.