accomodating v6* branches

[rik-shaw]

Very minor changes here, but I have a couple questions:

1. Would we keep different branches for each iodé version? So "pf-build-iodeOS-v5" and "pf-build-iodeOS-v6"? As new_build.sh can accomodate all versions, I think a single branch is OK. But what about the change to the Dockerfile indicating that v6-staging is now the tracking branch instead of v5-staging? With that set to v6 is it still possible to make v5 builds?
2. Curious if we need to add a signature spoofing patch for Android 22.1? Or maybe as I understand now, custom spoofing patches are NOT needed since we build userdebug builds, and upstream LOS handles that.
3. I may have messed up in making a new PR for this so it is now accomodating v6* branches #741 instead of being linked to Changes needed to support Iodé 6 builds #740. I'll need to sort out how to tie a PR to an existing issues in the future.
4. I am not sure how to test locally, basically I would need to learn how to generate a new Docker image, correct? Hmm more learning ahead..
5. I noticed the pf-build-iodeOS branch is a few commits behind master do we need to apply any of those commits here?

[petefoth]

3. I may have messed up in making a new PR for this so it is now

I think you've done it OK. When this PR is merged, I think the issue will get closed automatically

4. I am not sure how to test locally, basically I would need to learn how to generate a new Docker image, correct? Hmm more learning ahead..

You don't actually need to do that - github takes care of that - check the 'Actionstab. Pushing a change in this repo will cause github to run some actions, one of which is building the docker image, and pushing it to Docker hub. If you look at https://hub.docker.com/r/lineageos4microg/docker-lineage-cicd/tags you will see there is an image with the:rik-740-iode6-support` tag. To test the change, you would just need to run that docker image. A full test would run it

1. once with BRANCH_NAME=v6.0 to prove that building Iodé6 works
2. once using BRANCH_NAME=v5.9 to prove you haven't broken building Iodé5
3. once with an invalid branch name to show that it still handles invalid branch names correctly

But it's not a big change, so we don't need to run a full test. As you can run builds very quickly now, you should probably run a v6.0 build as that is the functionality you have added

5. I noticed the pf-build-iodeOS branch is a few commits behind master do we need to apply any of those commits here?

Good spot. We do need to address that, but let's do it after we've merged this PR

So, over to you to address my review comment, and maybe run a test build.

[petefoth]

I think we should leave this as v5-staging. Variable values set in this file are the default, used if variable is not set in the docker run command. In practice, we always specify a branch name in the docker run command so it's not a big deal. In the master branch the default branch name was lineage-16.1 until I changed it last week 😄
I'm going to say 'please change this', mainly so you can find out how you modify a Pull Request (you just make and push a new commit in the branch, and it appears 'automagically' in the PR)

Also I'm going to use the Start a review button for this comment, because I've never used it before, and I want to see how it works when there's more than one person on a project 😄

[rik-shaw]

But it's not a big change, so we don't need to run a full test. As you can run builds very quickly now, you should probably run a v6.0 build as that is the functionality you have added

I am running a v6.0 bonito build now using the :rik-740-iode6-support branch. I hadn't realized that the action was building all branches, but yes that makes it easy to test that way. It is a very small change but I was a bit afraid of not testing it before merging into the actual :pf-build-iodeOS branch, as I probably should be :-)

[rik-shaw]

@petefoth the v6.0 bonito build using my pr branch has installed correctly, I don't notice any issues (I went through the basic setup of it, seems all hardware etc is working). I'll defer to you to merge when and if you see fit :-) Probably a reasonable process to follow to not merge our own PRs :-)

[petefoth]

I'll defer to you to merge when and if you see fit :-)

Merged.

Probably a reasonable process to follow to not merge our own PRs :-)

Agreed. except in the case of 'emergencies'. Definition of 'emergency' TBD, but we'll know when it happens 😄