GoogleChromeLabs / bubblewrap

Bubblewrap is a Command Line Interface (CLI) that helps developers to create a Project for an Android application that launches an existing Progressive Web App (PWAs) using a Trusted Web Activity.
Apache License 2.0
2.29k stars 152 forks source link

Difficult to fully automate this (CI/CD) #806

Open iBotPeaches opened 1 year ago

iBotPeaches commented 1 year ago

Describe the bug Unable to make this truly non-interactive and supported in a GitHub Action

To Reproduce (GitHub Action - Ubuntu 22.04)

  1. npx bubblewrap updateConfig --jdkPath="$JAVA_HOME_11_X64" --androidSdkPath="/usr/local/lib/android/sdk";
  2. npx bubblewrap doctor && npx bubblewrap build

Expected behavior I wish for it to work.

Screenshots

,-----.        ,--.  ,--.  ,--.
|  |) /_,--.,--|  |-.|  |-.|  |,---.,--.   ,--,--.--.,--,--.,---.
|  .-.  |  ||  | .-. | .-. |  | .-. |  |.'.|  |  .--' ,-.  | .-. |
|  '--' '  ''  | `-' | `-' |  \   --|   .'.   |  |  \ '-'  | '-' '
`------' `----' `---' `---'`--'`----'--'   '--`--'   `--`--|  |-'
                                                           `--'    
? Do you want Bubblewrap to install JDK?
  (Enter "No" to use your JDK installation) (Y/n) 
Error: Process completed with exit code 130.

Desktop (please complete the following information):

Additional context I thought I was using this wrong, so I peeked at the official action and tried out the container with:

 docker run --rm -ti ghcr.io/googlechromelabs/bubblewrap:latest build --config config.json
 ,-----.        ,--.  ,--.  ,--.
|  |) /_,--.,--|  |-.|  |-.|  |,---.,--.   ,--,--.--.,--,--.,---.
|  .-.  |  ||  | .-. | .-. |  | .-. |  |.'.|  |  .--' ,-.  | .-. |
|  '--' '  ''  | `-' | `-' |  \   --|   .'.   |  |  \ '-'  | '-' '
`------' `----' `---' `---'`--'`----'--'   '--`--'   `--`--|  |-'
                                                           `--'    
? Do you want Bubblewrap to install JDK?
  (Enter "No" to use your JDK installation) (Y/n) 

However, it validates fine with doctor so I am confused why its asking for the SDK information like it doesn't exist in both my action and the official container.

,-----.        ,--.  ,--.  ,--.
|  |) /_,--.,--|  |-.|  |-.|  |,---.,--.   ,--,--.--.,--,--.,---.
|  .-.  |  ||  | .-. | .-. |  | .-. |  |.'.|  |  .--' ,-.  | .-. |
|  '--' '  ''  | `-' | `-' |  \   --|   .'.   |  |  \ '-'  | '-' '
`------' `----' `---' `---'`--'`----'--'   '--`--'   `--`--|  |-'
                                                           `--'    
doctor Your jdkpath and androidSdkPath are valid.
andreban commented 1 year ago

Thanks @iBotPeaches.

Would you have a suggestion for how the automation configuration should look like? It sounds like passing the JDK and Android SDK paths in some other way might be more idiomatic?

One problem I'm seeing is that the Android SDK needs to install the Build Tools the first time it runs, and the license agreement must be accepted (this is outside the control of Bubblewrap).

iBotPeaches commented 1 year ago

Would you have a suggestion for how the automation configuration should look like? It sounds like passing the JDK and Android SDK paths in some other way might be more idiomatic?

The tool itself I think struggles in a degree to automation. Take the manifest file it generates - its full of values that want to be controlled/changed in automation. The version(s), the path(s) and the urls, etc.

So the WIP action I have basically builds a config file on the fly, but then it fails - because there is no hash file for it. Thankfully the hash is just a sha1, so very easy to "fake" it and go forward. So I'm making progress little by little, but a slow journey.

In terms of the paths for tools - the doctor command to setup the config file was fine. Originally I was hoping it was just envs/params the whole way down, but I had to jump through some docs/history to easily find what those would be.

One problem I'm seeing is that the Android SDK needs to install the Build Tools the first time it runs, and the license agreement must be accepted (this is outside the control of Bubblewrap).

Much like the pattern I saw in the existing Dockerfile just issuing "y" towards a specific script will probably resolve this. The GitHub Actions images I'm using are pre-accepted, so I wasn't even considering that a possible issue. You can see here: https://github.com/actions/runner-images/issues/7506#issuecomment-1533097084 for where I learned that.

I wasn't aware the warning I was seeing was because the license was not agreed. If that is the only remaining issue - it seems like this will be easier to resolve than I thought. I think if I understood properly, if I get the container working non-interactively I should expect the GitHub Action route to work.