Modify deploy_docs script to include Android

[danielnugraha]

Issue

Description

The Android SDK doesn't have any API reference, so it's great to have one to soften the learning curve for users using our API.

Related issues/PRs

Proposal

Explanation

Build setup to generate API reference in html, basic styling to conform to Flower design guidelines and logo change are applied. Also the deploy_docs.sh is updated to generate android API reference. Changes base on Android SDK, merge only after Android SDK is merged.

Checklist

• Implement proposed change
• Write tests
• Update documentation
• Update changelog
• Make CI checks pass
• Ping maintainers on Slack (channel #contributions)

Any other comments?

[tanertopal]

Suggested change

	on:
	pull_request
	on:
	push:
	branches:
	- main

[danielnugraha]

Do we always wants to deploy the docs on pull request?

[tanertopal]

You are right. We don't. I adjusted the suggestion.

[tanertopal]

Can we rename .github/workflows/android-release.yml to .github/workflows/android.yml?

[danielnugraha]

Can we rename .github/workflows/android-release.yml to .github/workflows/android.yml?

In Android, we need a release that generates the artifacts and send it to maven central. Also ideally, after the release, the docs is built and deployed in our flower.dev website. What is the best way to achieve this? I don't think deploying the docs after a pull request is merged is suitable in this case.

[tanertopal]

@danielnugraha, regarding the renaming of the CI YAML file, I just want to ensure that each team knows which YAML file belongs to their work. It could be clearer right now. Having just android.yml is, for me, as we have a mono repo, and the number of YAML files is getting out of control.

wrt to your comment about when to deploy the Android docs, you mentioned the following two options (correct me if I misread):

1. Deploy on each commit to main
2. Deploy on each release

I am undecided. In the Python code base, we used to deploy on each push to merge and switched now to having versioned docs + latest docs.

I am okay with deploying only on each release for Android. In the case of the iOS docs which we just merged, we deploy on each commit to main - although the swift release is in sync with that, right?

@danieljanes any thoughts on this?

[danielnugraha]

@danielnugraha, regarding the renaming of the CI YAML file, I just want to ensure that each team knows which YAML file belongs to their work. It could be clearer right now. Having just android.yml is, for me, as we have a mono repo, and the number of YAML files is getting out of control.

wrt to your comment about when to deploy the Android docs, you mentioned the following two options (correct me if I misread):

1. Deploy on each commit to `main`

2. Deploy on each release

I am undecided. In the Python code base, we used to deploy on each push to merge and switched now to having versioned docs + latest docs.

I am okay with deploying only on each release for Android. In the case of the iOS docs which we just merged, we deploy on each commit to main - although the swift release is in sync with that, right?

@danieljanes any thoughts on this?

I've changed the script name to android.yml, should I separate the publishing and deploying the docs? The publishing can be complicated if it triggers on every pull request merge.