-
Notifications
You must be signed in to change notification settings - Fork 627
Implement the GitSubmodulePlugin #4623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Javadoc Changes:--- /home/runner/diff/original/firebase-kotlindoc/android/com/google/firebase/database/FirebaseDatabase.html 2023-02-06 22:14:01.491894292 +0000
+++ /home/runner/diff/modified/firebase-kotlindoc/android/com/google/firebase/database/FirebaseDatabase.html 2023-02-06 22:06:44.288026205 +0000
@@ -122,7 +122,7 @@
<tr>
<td width="40%"><code>synchronized void</code></td>
<td>
- <div><code><a href="/docs/reference/android/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="https://developer.android.com/reference/kotlin/java/lang/Object.html">Object</a> logLevel)</code></div>
+ <div><code><a href="/docs/reference/android/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html">Logger.Level</a> logLevel)</code></div>
<p>By default, this is set to <code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>.</p>
</td>
</tr>
@@ -462,7 +462,7 @@
</div>
<div><a name="setLogLevel-com.google.firebase.database.Logger.Level-"></a><a name="setloglevel"></a>
<h3 class="api-name" id="setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</h3>
- <pre class="api-signature no-pretty-print">synchronized public void <a href="/docs/reference/android/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="https://developer.android.com/reference/kotlin/java/lang/Object.html">Object</a> logLevel)</pre>
+ <pre class="api-signature no-pretty-print">synchronized public void <a href="/docs/reference/android/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html">Logger.Level</a> logLevel)</pre>
<p>By default, this is set to <code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>. This includes any internal errors (<code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#ERROR">ERROR</a></code>) and any security debug messages (<code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>) that the client receives. Set to <code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#DEBUG">DEBUG</a></code> to turn on the diagnostic logging, and <code><a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html#NONE">NONE</a></code> to disable all logging.</p>
<div class="devsite-table-wrapper">
<table class="responsive">
@@ -473,7 +473,7 @@
</thead>
<tbody class="list">
<tr>
- <td width="40%"><code>@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="https://developer.android.com/reference/kotlin/java/lang/Object.html">Object</a> logLevel</code></td>
+ <td width="40%"><code>@<a href="https://developer.android.com/reference/kotlin/androidx/annotation/NonNull.html">NonNull</a> <a href="/docs/reference/android/com/google/firebase/database/Logger.Level.html">Logger.Level</a> logLevel</code></td>
<td>
<p>The desired minimum log level</p>
</td> --- /home/runner/diff/original/firebase-kotlindoc/kotlin/com/google/firebase/database/FirebaseDatabase.html 2023-02-06 22:14:01.551896533 +0000
+++ /home/runner/diff/modified/firebase-kotlindoc/kotlin/com/google/firebase/database/FirebaseDatabase.html 2023-02-06 22:06:44.320027220 +0000
@@ -122,7 +122,7 @@
<tr>
<td width="40%"><code>synchronized <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/index.html">Unit</a></code></td>
<td>
- <div><code><a href="/docs/reference/kotlin/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(logLevel: <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/index.html">Any</a>)</code></div>
+ <div><code><a href="/docs/reference/kotlin/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(logLevel: <a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html">Logger.Level</a>)</code></div>
<p>By default, this is set to <code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>.</p>
</td>
</tr>
@@ -462,7 +462,7 @@
</div>
<div><a name="setLogLevel-com.google.firebase.database.Logger.Level-"></a><a name="setloglevel"></a>
<h3 class="api-name" id="setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</h3>
- <pre class="api-signature no-pretty-print">synchronized fun <a href="/docs/reference/kotlin/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(logLevel: <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/index.html">Any</a>): <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/index.html">Unit</a></pre>
+ <pre class="api-signature no-pretty-print">synchronized fun <a href="/docs/reference/kotlin/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)">setLogLevel</a>(logLevel: <a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html">Logger.Level</a>): <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/index.html">Unit</a></pre>
<p>By default, this is set to <code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>. This includes any internal errors (<code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#ERROR">ERROR</a></code>) and any security debug messages (<code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#INFO">INFO</a></code>) that the client receives. Set to <code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#DEBUG">DEBUG</a></code> to turn on the diagnostic logging, and <code><a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html#NONE">NONE</a></code> to disable all logging.</p>
<div class="devsite-table-wrapper">
<table class="responsive">
@@ -473,7 +473,7 @@
</thead>
<tbody class="list">
<tr>
- <td width="40%"><code>logLevel: <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/index.html">Any</a></code></td>
+ <td width="40%"><code>logLevel: <a href="/docs/reference/kotlin/com/google/firebase/database/Logger.Level.html">Logger.Level</a></code></td>
<td>
<p>The desired minimum log level</p>
</td> |
📝 PRs merging into main branchOur main branch should always be in a releasable state. If you are working on a larger change, or if you don't want this change to see the light of the day just yet, consider using a feature branch first, and only merge into the main branch when the code complete and ready to be released. Add the 'main-merge-ack' label to your PR to confirm merging into the main branch is intended. |
For the release job, isn't it easier to just add the following to our workflow config? with:
submodules: true |
Unit Test Results 399 files ±0 399 suites ±0 18m 14s ⏱️ +14s For more details on these failures, see this check. Results for commit 83a86c2. ± Comparison against base commit fea70f7. ♻️ This comment has been updated with latest results. |
Coverage Report 1This report is too large (197,377 characters) to be displayed here in a GitHub comment. Please use the below link to see the full report on Google Cloud Storage.Test Logs |
Good question. Yes and no. While it would quickly and easily fix the release job, that's only in the context of the workflow. The underlying task itself would still be broken. So if you were to be debugging this locally, it wouldn't align with what you would get from the workflow. Additionally, this may come up in several places in the future regarding submodules not being initialized for a build. I believe it'd be much easier long-term, and more robust- to instead fix it at the build level versus the workflow level. WDYT? |
Size Report 1Affected ProductsNo changes between base commit (fea70f7) and merge commit (7c166a3).Test Logs |
Startup Time Report 1Note: Layout is sometimes suboptimal due to limited formatting support on GitHub. Please check this report on GCS. Startup time comparison between the CI merge commit (7c166a3) and the base commit (fea70f7) are not available. No macrobenchmark data found for the base commit (fea70f7). Analysis for the CI merge commit (7c166a3) can be found at: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we vision that going forward product teams shall manipulate submodules only through gradle?
- If so, do we need to support other submodule commands? Not sure if all existing submodule use scenarios are covered.
- If not, can product teams run standalone git submodule commands? Will they be interfered with implicit invocations from gradle?
Only in the context of it being a requirement for any given gradle task. So if they need certain submodule actions to occur before a build, or before an artifact is generated- then ideally this would be bound via gradle. Aligns with keeping tasks aligned with one another, is more easily conveyed, and in the context of gradle specifically- allows us to take advantage of gradle cache & speed optimizations.
Right now, we only have one place using submodules at all. Should more teams start to use them in more elaborate ways (that have implications for other gradle tasks) then we can expand this. I intentionally wrote this in a way to which adding additional functionality in the future will be as painless as possible. But seeing as there is only one usage of submodules right now (fetching them)- this avoids unnecessary implementation / maintenance overhead. I'd like to cover our use cases rn, as it has implications for our current issues, and re-visit in the future as needed- as we have more pressing tasks on our plate.
Absolutely. These tasks track state via the actual state of the module, and will skip when the task is unnecessary. |
793a7b1
to
83a86c2
Compare
Per b/267779128,
This adds a new Plugin called
GitSubmodulePlugin
. It's a light weight plugin that facilitates interaction with Git Submodules from Gradle.Our current release action is broken (b/267188389), because we have SDKs with submodules- but never actually pull the submodules as apart of our build process. We could get away with just a quick little hacky task to fix this, but I opted for a Plugin instead. Primarily to take advantage of the following benefits:
Documentation is provided as annotations in KDoc form for everything added, including the tasks themselves. Namely, the plugin adds three tasks:
initializeGitSubmodules
updateGitSubmodules
removeGitSubmodules
Each task is annotated with background information on what it does.
Note that this plugin also binds the updating of submodules to the build process, so this immediately fixes our release pipeline without further action.