Unable to create new analytics settings: /opt/android-sdk-linux/analytics.settings (Permission denied)

[typeless]

Unable to create new analytics settings: /opt/android-sdk-linux/analytics.settings (Permission denied)

Will submit a PR later on when tested ok.

[mindrunner]

When does that happen?

[typeless]

@mindrunner When building an Android project using Gradle. I am on short days off, so not available until next week. Last time I tried my fix, I encountered some error related to our build infra, which I haven't figured out. My fix was to add a chmod 0777 ... at https://github.com/mindrunner/docker-android-sdk/blob/master/tools/entrypoint.sh#L11. I thought that would work.

[mindrunner]

Do you use the container as a sidecar or do you build directly with that image?

[typeless]

@mindrunner I use the image directly.

[typeless]

I need to run the container with a non-root user. Otherwise, if I run it with root, it works correctly.

[mindrunner]

Can you give me the exact command you use for starting the build?

[typeless]

kind: pipeline
name: default

steps:
- name: build
  image: runmymind/docker-android-sdk
  commands:
    - ./make.sh

- name: release
  image: runmymind/docker-android-sdk
  commands:
    - apt-get update && apt-get install -y zip
    - ./release.sh
  depends_on:
    - build
  when:
    event: tag

- name: gitea_release
  debug: true
  image: plugins/gitea-release:latest
  settings:
    insecure: true
    base_url: http://192.120.100.175:3000
    api_key:
        from_secret: gitea_token
    files:
      - PosService/build/outputs/aar/*.zip
    checksum:
      - md5
      - sha256
  depends_on:
    - release
  when:
    event: tag

The above is the Drone CI configuration.

The content of make.sh: ./gradlew clean build assembleAndroidTest

I run the build with drone exec. But the drone-cli is a modified version which would run with a non-root user.

[typeless]

It turned out chmod -R 0777 /opt/android-sdk-linux is the only working solution.

[typeless]

I gave up running the container with a different user.

[mindrunner]

Hi this images is supposed to be used as a user with the UID 1000. There is no real clean solution to enable it for all users. The chmod thing has some drawbacks, this is why I did not put it in.

In your example, I do not see any usage of another user, so I would assume, it should be working.

Why do you need to run this as another user?

[typeless]

I intended to use Drone CLI as a build-farm controller for containerized builds. So, we can build our sources using the CI infrastructure without first pushing to the Git hosting server. Currently, the Drone CLI can run the build pipelines for a local source tree by sharing the host working directory as the container's volume. But the generated binary and other by-products are owned by root. That makes my colleagues who don't have sudo privilege unable to remove those files.

[typeless]

Another approach I can find is to use docker cp. But it doesn't seem to be usable when the output files are enormous (like more than 10GB). The particular example we encounter is the builds of Android BSP. Other smaller projects are probably ok with the way.

[mindrunner]

But the generated binary and other by-products are owned by root.

This should definitely never be the case. Actually, this means (probably), that the build ran as the root user. Can you confirm that? Why do you build as root?

I do not know Drone. Never used it. I am happy to have a look at your build system, if you would like me to.

[typeless]

I’m not at my computer but iirc that’s true. And I think that’s due to drone runs the image with the root user argument.

I’ll have a look. Anyway, I appreciate your help 🙏

[mindrunner]

It seems like the image from the 'latest' tag is using the root user per default. this should not be the case. I will investigate this.

[mindrunner]

I just saw that I left this open and forgot about it. Is this still an issue for you @typeless?

I am investigating now if I can reproduce my assumptions here.

[mindrunner]

Alright, I checked the git history and it seems that from the beginning, this was running as the root user per default. I remember that I have had reasons for doing this. If you look at https://github.com/mindrunner/docker-android-sdk/blob/master/tools/entrypoint.sh you will see that the SDK update is done as the UID 1000.

This images were never created to run in another environment than the internal CI/CD system of the company I was working for. Thus, there might be issues with running it on other CIs.

Maybe it is a good idea to re-evaluate this and maybe change the default user to UID 1000 as well. However, this sounds like a big change to me and should be tested thoroughly.

I am not actively working on this at the moment and do not have a lot of time, but I am happy to see, review and merge PRs if there are some!

[typeless]

@mindrunner No, I don't have the issue anymore. I forgot how I fixed it too :) I do still run the image for my projects. Thanks.

[mindrunner]

Alright, closing it here until someone thinks that this is an issue :)