[ci] Add parameters to set the base branch

[jabesq]

This change should be applied on master and release/6.9.x too

Proposed changes

• Add release_ref parameter in config.yml to set the base reference used for pycti and connectors_sdk in connectors, instead of using master

Related issues

• Close [ci] Update pycti version used in run_test.sh #5959

Checklist

• I consider the submitted work as finished
• I have signed my commits using GPG key.
• I tested the code for its functionality using different use cases
• I added/update the relevant documentation (either on github or on notion)
• Where necessary I refactored code to improve the overall quality

Further comments

[efaure]

@jabesq Good job on this.
A few remarks:

• I think it would be better to make a PR on master that will handle the branch management in all situation and then to report it on lts and 6.9
• From what I understand, you define "release_ref" as a default parameter, so it means that we would have to change this default parameter each time we create a new branch. There is a high risk that this manipulation will be forgotten and break the future new LTS start

imo, it will be more future proof to set the release_ref value depending on the same of the current branch:

• if we are on a branch starting with "lts" or 6.9 we set release_ref with the branch name
• if all other cases (master and feature branch) we set it with "master" value

wdyt @helene-nguyen

[jabesq]

• I think it would be better to make a PR on master that will handle the branch management in all situation and then to report it on lts and 6.9

Yes, you are right this PR should be applied on all our main branches (master, release/6.9.x and lts/7.260309.0 ) I've just create this PR on top lts/7.260309.0 to be in the "worse" condition (CircleCI doing a shallow clone of just the current branch and the default one `master)

• From what I understand, you define "release_ref" as a default parameter, so it means that we would have to change this default parameter each time we create a new branch. There is a high risk that this manipulation will be forgotten and break the future new LTS start

imo, it will be more future proof to set the release_ref value depending on the same of the current branch:

• if we are on a branch starting with "lts" or 6.9 we set release_ref with the branch name
• if all other cases (master and feature branch) we set it with "master" value

We discussed this with @helene-nguyen, and it may lead to some issues. For instance, if we need to deploy a patch only on an lts branch (like this particular PR) in the future, the patch branch must follow a specific pattern; otherwise, it might be built against the wrong version. Additionally, we will need a complex regex when we have at least two LTS branches within six months to distinguish which LTS we are targeting..
What i'll try instead is to use the variable pipeline.event.github.pull_request.base.ref when the build is triggered a PR, otherwise try to find the closest ancestors between master and any lts branch (and release/6.9.x)

[efaure]

@jabesq Nice, if the pipeline.event.github.pull_request.base.ref is working it's a clean option.
I'm interested to know if it works as expected.
Circle CI build are triggered on commit, I'm not sure of how it's able to retrieve PR information.
If you can retrieve the base.ref for PR, you'll still have to test 2 cases:

• pipeline launched from a commit on a feature branch with PR
• pipeline launched from commit on master (or lts branch) : in this case you may not have a base_ref and need to use the "branch" instead.