tags on the release manifest repo do not hold as much meaning in /e/ as they’d do for an individual code project - the upstream manifest revisions for most of the aosp and lineage repos do not change with every minor revision (still dozens, but no turmoil) - so what you get is mainly updated package forks from the main git-lfs prebuilt repo with what you’d see in lineage weeklies anyway
Still feels non-deterministic; might run build one day and it succeeds, while another day it fails. At the very least I’m going to get different versions of dependencies and building external stuff on top of a moving target branch, rather than a point-in-time tag, just feels error prone and plain wrong.
Building v1-s for FP4 target has failed. Will start a new thread with some details.
The Docker image can work it all out: it sees that the BRANCH_NAME is a tag, so it automatically adds the refs/tags/ prefix - see
https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/blob/master/src/build.sh#L94-99
So when I use the followiing docker run command:
docker run \
-v "/srv/src:/srv/src" \
-v "/srv/zips:/srv/zips" \
-v "/srv/logs:/srv/logs" \
-v "/srv/cache:/srv/ccache" \
-v "/srv/keys:/srv/keys" \
-v "/srv/local_manifests:/srv/local_manifests" \
-v "/srv/userscripts:/srv/userscripts" \
-e "SIGN_BUILDS=true" \
-e "INCLUDE_PROPRIETARY=false" \
-e "RELEASE_TYPE=CUSTOM" \
-e "CLEAN_AFTER_BUILD=true" \
-e "BRANCH_NAME=v1.12.3-r" \
-e "DEVICE_LIST=z3tc,z3tcw" \
-e "REPO=https://gitlab.e.foundation/e/os/releases.git" \
registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community
I see the following line in the log file
>> [Wed Jul 5 14:26:13 UTC 2023] Branch name v1.12.3-r is a tag on e/os/releases, prefix with refs/tags/ for 'repo init'
1 Like
pete, as written, there’s a bug in the lines you quote currently. Run that curl without grep -q and you’ll see. Maybe this works for you because you didn’t pull the image from the registry since that part of the code was merged. See the MR, it’s just a url param error
that said: putting dynamic elements into scripts is… on top of bash, you get no stacktraces, no failure attribution, just the next echo that happens to come up
I am looking at the master branch, and according to git blame those lines were added between 3yrs ago and 5 months ago. The curl ... line was added buy you.
The docker run command I quoted was run on 5th July this year on a ‘clean’ cloud server. My log file shows that the lastest image (on that date) was downloaded. I have been using tags to build /e/OS with docker for quite a long time now: it has always worked for me
nah, not in that form - git commits are just text when unsigned. I authored the commit that brought up the discussion, it wasn’t merged as authored, see MR for the real links.
I’m not sure what I’m discussing: as said I welcome the script, but anybody using either the lineage4microg or the /e/ fork version (that introduced more dynamic elements / regexes for subtle failure) will have difficulties when things break because bash is just not good at bubbling up errors
Me neither 
All I know is that the latest docker-lineage-cicd:community image works for me if I use tags, and -e "REPO=https://gitlab.e.foundation/e/os/releases.git" . I can see that using a branch name on https://gitlab.e.foundation/e/os/releases.git, or using a tag on https://gitlab.e.foundation/e/os/android.git might fail, possibly because of the typo in the curl command.
in its current defective form (we’re discussing one symbol really) the repo init + sync will not fail if the tag name also exists as branch reference, then the logic doesn’t matter because there is fallback.
But if both references exist, a tag will always take precedence. As originally intended, but it’s subtle, users might not be aware of it because of the variable name (BRANCH_NAME) - and that is why I don’t like it - but tried to fix 2 times anyway, because a all-in-one-build-command is a good entry level asset.
A sensible course forward would be to use separate arg flags and variable names to differentiate tags from branches.
This topic was automatically closed after 90 days. New replies are no longer allowed.