ci_toolkit migration

[wzieba]

Follow up of #36

[wzieba]

I think your suggestion @AliSoftware will work, although there's an issue with permissions now. CI fails with Warning: Failed to read or create install properties file. and it led me to this SO answer - what would you say is the best way to address? I guess calling sudo here is not an option.

[AliSoftware]

Mmmh damn. Not sure tbh.

I'd not be that surprised if that was in the context of a Docker container installing stuff on the host (via shared volume) because we know inside Docker the user is usually mapped to user 0 = root by default.
But I'm surprised that the android SDK would be installed as root in the android agent when this code runs here. Did you check (e.g. ls -l to debug) that Unix permissions/ownership was the root cause (no pun intended 😛) of the installation failure, and not something else?

[wzieba]

So:

• the permissions for sdkmanager are -rwxr-xr-x.
• the owner of sdkmanager (and I guess: the whole /usr/local/android) is ec2-user
• the current user is buildkite-agent (had to check)

I guess that it's not solely permission issue for sdkmanager (because it has x for other) but rather the whole /usr/local/android directory (as suggested in SO).

I wanted to change permission of sdkmanager (just to test) but as expected - it fails.

I wonder what are our options, I'll debug it further but wanted to leave breadcrumb.

[AliSoftware]

Ah, right, that makes sense.

And what confused me at first is that I was sure that we used sdkmanager to install stuff in other cases / apps / repos in our command scripts… but maybe I confused it with avdmanager (which I think doesn't install AVDs in /usr/local/android?)… or maybe the packages we install with sdkmanager in those cases I was thinking of… are different type of packages, that are installed elsewhere? 🤔 Or maybe what I was thinking about was for Appium tests in Android, which use a different agent (ad runs on Mac machines, not Docker nor AWS AMIs), so context is different…

Anyway, in the end not sure if there's a better solution than to add the NDK to the agents at provision time in the Ansible Playbook and redeploy them. And sure, if we later need a newer version of the NDK we'll have to update the agent and redeploy once again… but I guess it's similar to how we handle the JDK in a way, right?

[wzieba]

Thanks for the link to Ansible Playbook! I was looking for something like this. Yes, that might be the case - although NDK is really needed only here, so I'd prefer to install it here only. But if there's no other way, I'll prepare a PR for Ansible Playbook.

[AliSoftware]

Cc @crazytonyli @jkmassel in case you think of a way to only install it locally by the pipeline (and working around the unix permissions issues of being different users) as opposed to installing it at agent deployment time for everyone like I suggested above?

[crazytonyli]

In terms user/group of the buildkite-agent and ec2-user users, I think they are suppose to be in the same group.

However, I think this task is configured wrong: It's adding ec2-user to the buildkite-agent group, instead of the other way around.

- name: Add Buildkite user to ec2-user group
  user:
    name: 'ec2-user'
    groups: buildkite-agent
    append: true

[wzieba]

btw I've discussed this with @jkmassel on 1:1 and it'd be probably best to add NDK installation to Ansible.