not clean environment after ci and more

[alrocar]

Added some changes:

• If there's a requirements.txt in the data project it has precedence over pip install tinybird-cli, that way you have more control over the CLI version used.
• Environments are now created with the pull request number and they are only deleted on merge or closed PR. This has been only tested on GitHub workflows and requires update existing projects to add the closed event.
• release_* jobs are now run manually on GitHub.
• source .tinyenv before running regression tests so you can export env variables like OBFUSCATE_REGEX_PATTERN
• Adds all same changes for GitLab

[alrocar]

I've updated the PR description with the changes included it.

The plan is test them with ci_analytics in GitHub and Internal in GitLab and then release a v2.3.0 and update the CLI so it generates new ci/cd templates based on that version.

Changes are not fully backwards compatible, in order to clean up Environments rules of execution of the CI pipelines both in GitHub and GitLab need to be updated. I'll add it to the release notes and we have to think on a way to communicate to users.

[alrocar]

Tested both in GitHub and GitLab.

In order to keep Environments between CI runs:

• In GitHub you have to add types: [opened, reopened, labeled, unlabeled, synchronize, closed] to tinybird_ci.yml

• In GitLab you have to, change the ci_cleanup rule to be the same as the cd one, for instance:

- &cli_telemetry_cleanup_rule
    if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    changes:
      - .gitlab-ci.yml
      - cli_telemetry/**/*
    when: always

And remove needs: ["run_ci__whatever"] from the ci_cleanup job.

If no change is applied and you update to use this template, the behaviour is the same as before in GitLab. In GitHub, CI environments are not cleaned after merge, so users will notice and when they reach the limit we can tell them to include the closed event.

[xavijam]

What if we update the CLI with the new changes to a production version and then we release the new CI/CD changes? With that we will avoid to point to a pre-release version

[alrocar]

What if we update the CLI with the new changes to a production version and then we release the new CI/CD changes? With that we will avoid to point to a pre-release version

Yes, I'd do that but first let's merge this PR and integrate in some of our internal projects (using directly the main branch) during next week. If everything goes OK then we can:

• Release v2.3.0 of this repo
• Release stable version of the CLI including a reference to v2.3.0
• Notify users about changes

WDYT?

[xavijam]

Fine by me, let's go!

[alrocar]

Added a changelog to not forget about these changes and use them as release notes