Recall that `test-lab.py` uses `parse-ui-test.py` and `parse-ui-test-fromfile.py` to parse test results, depending on the test type. `parse-ui-test-fromfile` can produce better failure messages, including the test class and test name.
The strategy here is to first run `parse-ui-test-fromfile` (subject to test type, as before), noting whether it produced a treeherder-friendly failure message; then run `parse-ui-test` (for all tests, as before) passing a new argument to print any failures in the treeherder-friendly way, only if `parse-ui-test-fromfile` did not report failures. Most of the complexity is to avoid duplicate reporting, favouring the more granular failure messages from `parse-ui-test-fromfile`.
Differential Revision: https://phabricator.services.mozilla.com/D204684
7166: Closes https://github.com/mozilla-mobile/android-components/issues/7165: Handle untracked directories during auto-publish r=rocketsroger a=grigoryk
Our python script would blow up if it encountered an untracked directory. This changes how the script reads in untracked files to account for this, and switches to git's hash-object to calculate hashes of files (instead of manually reading them into memory and hashing in python).
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>
Adds a python script which is responsible for checking if there are any local changes,
and publishing to mavenLocal if there are.
Before, consuming projects were responsible for this logic; now, they can simply call this command.
This also behaves differently from what fenix did.
Before, to determine if there are changes we'd run the build, and see if any tasks were
actually performed (meaning, there were code changes that triggered a rebuild).
This way had its pros - it wouldn't consider changes to .gitignore, for example, as something that would
affect the build.
However, for the most common case, when there are no changes, this approach would still run through the build.
Doing so comes with a significant overhead of running through all of gradle's build phases, even if there isn't
actually anything to re-compile.
New approach optimizes for the common case. When there are no changes, we can now determine that almost instantly
by looking at an aggregate of git hash values for our project. And, by allowing consuming projects to call the python
script directly, we're skipping the gradle overhead as well.
The end result is a zero-cost auto-publication workflow.
5967: Add nightly releases to compete snapshots - part 1 (building) bors r=JohanLorenzo,pocmo r=JohanLorenzo,pocmo a=MihaiTabara
Motivation for this is https://github.com/mozilla-mobile/android-components/issues/5023
WIP - ~just a stub for now~ I still need to address a bunch of things like ~artifacts exposure~, beetmover and signing jobs, etc. But the main blocker is the fact that we need to create a new subdomain within maven.mozilla.org, something like https://nightly.maven.mozilla.org/.
Later edit: this seems to be working locally just fine. Adds the `nightly-release` graph succesfully and the version to be used is e.g. `public/build/browser-awesomebar-32.0.20200212190116-sources.jar` placed within
```
"payload": {
"artifacts": {
"public/build/browser-awesomebar-32.0.20200212190116-sources.jar": {
"expires": {
"relative-datestamp": "1 year"
},
"path": "/builds/worker/checkouts/src/components/browser/awesomebar/build/maven/org/mozilla/components/browser-awesomebar/32.0.20200212190116/browser-awesomebar-32.0.20200212190116-sources.jar",
"type": "file"
},
```
Co-authored-by: Mihai Tabara <mtabara@mozilla.com>
