Automattic
Add dependency analysis step to default CI pipeline
Description
@MiSikora suggested running the dependency analysis check on every CI build, internal ref pdnsEh-1QL-p2, and there seemed to be appetite for it.
This draft PR aims to get the work started...
One argument against adopting this, and which I guess was the rationale for running the check on a schedule, is that it takes a good 10+ minutes to run. If this were to become a requirement for the PR to be merged, it might slow down the dev cycle.
Having said that, it's something that would be easy to try to find out directly, and revert if necessary.
Implemented
- Add the check to the default pipeline, that is, run the check on every standard CI build
To Do
- Update the configuration to be as strict as possible – I don't actually know if that's required but the wording of the request made me think so. Plugin docs https://github.com/autonomousapps/dependency-analysis-gradle-plugin/wiki/Customizing-plugin-behavior
- Moving the check to run on every build makes the existing schedule redundant, so I would suggest removing it. This is a two step task:
- Remove from this repo
- Remove the schedule configuration on the Buildkite end
- If/when this PR lands on
main, update the GitHub configuration to require the "Dependency Analysis" step check
Testing Instructions
See CI build: TBD
Screenshots or Screencast
Checklist
- [x] If this is a user-facing change, I have added an entry in CHANGELOG.md
- [x] Ensure the linter passes (
./gradlew spotlessApplyto automatically apply formatting/linting) - [x] I have considered whether it makes sense to add tests for my changes
- [x] All strings that need to be localized are in
modules/services/localization/src/main/res/values/strings.xml - [x] Any jetpack compose components I added or changed are covered by compose previews
- [x] I have updated (or requested that someone edit) the spreadsheet to reflect any new or changed analytics.
I have tested any UI changes...
- [x] with different themes
- [x] with a landscape orientation
- [x] with the device set to have a large display and font size
- [x] for accessibility with TalkBack
| 1 Message | |
|---|---|
| :book: | This PR is still a Draft: some checks will be skipped. |
Generated by :no_entry_sign: Danger
📲 You can test the changes from this Pull Request in 📱 Mobile by scanning the QR code below to install the corresponding build.
 |
App Name | 📱 Mobile |
| Build Type | debugProd | |
| Commit | e1b80236aaaf6fe692e021bdc9c9c399ebefe3af | |
| Direct Download | pocketcasts-app-prototype-build-pr2815-e1b8023.apk |
📲 You can test the changes from this Pull Request in 🚗 Automotive by scanning the QR code below to install the corresponding build.
 |
App Name | 🚗 Automotive |
| Build Type | debugProd | |
| Commit | e1b80236aaaf6fe692e021bdc9c9c399ebefe3af | |
| Direct Download | pocketcasts-automotive-prototype-build-pr2815-e1b8023.apk |
📲 You can test the changes from this Pull Request in ⌚ Wear by scanning the QR code below to install the corresponding build.
 |
App Name | ⌚ Wear |
| Build Type | debugProd | |
| Commit | e1b80236aaaf6fe692e021bdc9c9c399ebefe3af | |
| Direct Download | pocketcasts-wear-prototype-build-pr2815-e1b8023.apk |
Just a thought: wouldn't it be better to run it inside GH Actions? This way it won't occupy any of our Buildkite workers. Or do we want to use Builtkite for mostly everything? I'm not really sure when do we use GH Actions and when do we use Buildkite.
Just a thought: wouldn't it be better to run it inside GH Actions? This way it won't occupy any of our Buildkite workers. Or do we want to use Builtkite for mostly everything? I'm not really sure when do we use GH Actions and when do we use Buildkite.
Our approach is to use Buildkite whenever we can as Buildkite workers are more performant and we have working configuration for collecting metrics from Buildkite.
We use GH Actions only when the benefits of using GH are high: e.g. for uploading Gradle dependencies to GitHub there is a first-class Gradle GitHub Action that handles both Gradle and GitHub API part for us. It's also not vital for performance, as resolving dependency graph is not that resource-consuming.
For dependency analysis I'd suggest we keep using Buildkite because we both need strong performance and we collect data from these builds.
After discussing this, we are not going to move forward with enabling this one every PR, not just yet. It is being too expensive for little benefit (ie. few PRs have the potential for such dependency related changes). But, we'll keep iterating on what's the best way to further integrate dependency analysis into our workflows, potentially blocking a PR from merging when a new advise presents itself (pdnsEh-1QL-p2#comment-4158).
