search

mingchen / docker-android-build-box

An optimized docker image includes Android, Kotlin, Flutter sdk.
https://hub.docker.com/r/mingc/android-build-box/
MIT License
556 stars 233 forks source link

CI: Fixup build and push #178 & minor improvements #179

Closed master-bob closed 9 months ago

master-bob commented 9 months ago

When tags where build & pushed to Docker Hub, the build arguments added in as a result of https://github.com/mingchen/docker-android-build-box/issues/116 where not included. This fix should make the tagged version use the correct build arguments. By doing so the correct docker image should be built and pushed to Docker Hub.

Tags which are affected by this on Docker Hub which should be re-pushed are 1.27.0 and 1.26.0.

This should resolve #178 .

mingchen commented 9 months ago

Thanks for the fix. Tags are not re-created to avoid conflict. Created tag 1.28.0.

master-bob commented 9 months ago

Thanks for the fix. Tags are not re-created to avoid conflict. Created tag 1.28.0.

I don't quite understand where the conflict would be. There was no issue with the affected tags, they where just built wrong. If the Github Action for the affected tags was manually re-run, then - as the build system should be fixed now - the correctly built tags would overwrite the ones on Docker Hub. Any affected users would just have to re-download the affected tags, this is the only conflict I see (between the old-invalid-affected-tag image and the new-valid-affected-tag image). Is there another conflict I am not seeing?

I don't know your workflow, so here are two workarounds:

One manner in which one can "manually re-run" the github action would be to do the following from the git command line, where origin is whatever you've named the github remote:

$git push --delete origin 1.26.0
To github.com:mingchen/docker-android-build-box.git
 - [deleted]         1.26.0
$git push origin 1.26.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:mingchen/docker-android-build-box.git
 * [new tag]         1.26.0 -> 1.26.0

as the same tag (with the same date) would be recreated on here on github, then the github action should trigger finally causing the build to be correctly pushed to docker hub.

If you use the GitHub UI after deleting the tag manually, then there are a couple of ways you could recreate the tag in the instructions provided by the community. The CLI manner above is better as I am unsure if the dates of the tag would persist

master-bob commented 9 months ago

Oh, I did more digging and checking. When the tag is built it uses the workflow at the tag time. So even by deleting and recreating the tag on origin, the new 1.28.0 workflow would not be used.

I think then the solution would be to create a new branches off 1.26.0 and 1.27.0. Then to cherry-pick the CI improvement onto each branch. Delete the old tag 1.26.0 and / or create a new tag on each fixed branch as 1.26.1 or what have you. Then push the new tags. And viola.

The CI improvement sha is 36051da02b33e4e9cd4d5d024ea17cfac9ad2498.