In my usecase, a python web server will be started in review jobs and currently I use pipeline ID to identify them.
The problem is that when new commits arrive, I can't find the pipeline ID of last pipeline of the environment in new pipeline to kill its process.
Therefore, a lot of orphaned pipelines are hanging in review server.
Environment name and slug can't be used since they are not numerical and can't be used as port number.
Proposal
Add CI_ENVIRONMENT_ID to CI variables.
Links / references
Documentation blurb
(Write the start of the documentation of this feature here, include:
To be used instead of CI_PIPELINE_ID for assigning ports to pipeline jobs
During implementation, this can then be copied and used as a starter for the documentation.)
First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria:
No activity in the past 12 months
No milestone (unscheduled)
We'd like to ask you to help us out and determine whether this issue should be reopened.
If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.
If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
This is straightforward to add but I wonder if this is a leaky abstraction? We do have a DB ID for environments but probably we don't want to expose this to users unless really necessary. The thing is that the name is already a unique identifier so should probably be sufficient for most use-cases. I can see that @reza.salkhordeh is wanting a numeric ID to use for a port number and while this may work it probably is not a great idea. For example these environment ids may exceed the port range limit of 65535 (and probably have already in some GitLab instances).
@reza.salkhordeh have you considered generating a consistent hash of the CI_ENVIRONMENT_NAME in a sensible range for ports? This will convert it into a consistent number that should allow you to use a consistent port number for the same environment.
We went hashing the CI_ENVIRONMENT_NAME path and it works fine in most cases.
The CI_ENVIRONMENT_NAME is unique in any given time. However, creating, deleting, and then again re-creating the branch causes some problems.
It's a minor issue which rarely happens.
Elliot Rushtonadded 1 deleted label and removed 1 deleted label
@DylanGriffith one use case for this is to be able to update the environment (URL [seems more likely] or name) if you can't define it at the .gitlab-ci.yml level, or because it is just more runner+process entanglement.
If it was available, I think you'd be able to just do:
GitLab Ultimate customer here. This is the EXACT issue I am trying to solve for. We deploy K8s resources using Helm charts. The chart allows for customizing the URL in the ingress(if desired). Therefore, the envionment:url property defined in my CICD yaml, won't match what gets deployed.
My work around right now is pulling the deployed URL from the helm manifest post-deployment, then trying to call the API to update the environment info. Currently, I have to call the API to query the environments, and parse the environment ID from the JSON response. This has been problematic in two main use-cases:
Using the search query param returns multiple results
The environment name is only 2 characters "QA", and the API returns an error because the search string is not long enough.
By making a variable named CI_ENVIRONMENT_ID would make like A LOT easier because the ID would be readily available, AND it would be guaranteed to match the exact environment I am trying to deploy to.
My use case is in an IaC deployment job, to set a tag on resources that points to the URL where the corresponding environment can be managed. But that URL only accepts the numeric environment ID—I tried $CI_PROJECT_URL/-/environments/$CI_ENVIRONMENT_SLUG and got a 404. So I grab the ID from the environments REST API. A variable with the full URL would work just as well.
We probably need to add this to Ci::Build#persisted_environment_variables because 1. we don't use Environment#predefined_variables anywhere except a special place 2. it's a persisted environment variable :)