Add `$CI_ENVIRONMENT_URL` as a build variable

Description

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7983 will add $CI_ENVIRONMENT_NAME and $CI_ENVIRONMENT_SLUG build variables. $CI_ENVIRONMENT_URL would be nice to have too, as it would allow .gitlab-ci.yml to be DRYed up, but is out of scope for that issue.

Proposal

We can't use the database column environments.url as the source of this data, as $CI_ENVIRONMENT_URL is the URL the environment will have if the deployment succeeds, and the deployment can't have succeeded until after the build has completed. So this needs adding to app/models/ci/build.rb, and should be calculated from the environment:url in .gitlab-ci.yml. Like $CI_ENVIRONMENT_NAME, it should undergo variable expansion. In particular $CI_ENVIRONMENT_SLUG should be an allowed variable for the environment URL.

Links / references

• https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7983#note_20004196
• http://docs.gitlab.com/ce/ci/environments.html
• http://docs.gitlab.com/ce/ci/yaml/README.html#environment

mentioned in merge request !7983 (merged)

This would be great. We have a CI job which notifies us via a chatroom when a deploy to a given environment completes. It would be nice if we could stick a link to the deployment URL in there too ('cos we're lazy).

I incorrectly assumed this was already available. We need to ping the final URL after our deploys complete (to trigger a few final upgrade steps), I thought we could just use the URL specified in the Environment URL. Looks like we'll need to add it as a separate Variable in the YAML file.

Sample Use Case

# deploy.sh

# Note: Our deploy script is 150+ lines long, this is just an example

# Ping update URL
curl "$CI_ENVIRONMENT_URL/upgrades/trigger.php"

# gitlab-ci.yml file
image: company/image-name:latest

deploy to production:
  stage: deploy
  environment:
    name: production
    url: https://our.live.site
  only:
   - master
  script:
   - deploy.sh

deploy to staging:
  stage: deploy
  environment:
    name: staging
    url: https://our.staging.site
  only:
   - develop
  script:
   - deploy.sh

For now, we'll just need to add a duplicate value to each deploy Job:

deploy to production:
  stage: deploy
  variables:
    ENVIRONMENT_URL: https://our.live.site
  environment:
    name: production
    url: https://our.live.site
  only:
   - master
  script:
   - deploy.sh

(Is it safe to use CI_ENVIRONMENT_URL as the variable name here so it works seamlessly if this feature is ever implemented?)

added ci variables label

mentioned in issue #31175 (closed)

changed milestone to %9.2

added Stretch label

changed milestone to %9.3

added Deliverable and removed Stretch labels

mentioned in issue #32638 (moved)

assigned to @godfat

@godfat Can you work on this issue?

mentioned in issue #32829 (closed)

@chrisatomix According to the document: https://docs.gitlab.com/ee/ci/variables/#priority-of-variables User defined variables have higher priorities. I am not sure if this is considered safe for you.

From some quick check, this seems to be quite simple to implement.

I am a bit unsure if we should persist this into database like environment name. I guess we should, because it doesn't hurt and it could be useful?

Digging into this more, now I remembered #26537 (moved). I still think that it's weird, confusing, and wrong, that creating a deployment would change the external URL for the environment. We could treat that as cache to the latest URL for the environment, but not the source of truth.

I think that external URL should belong to the deployment, rather than environment. It's also confusing that we could setup an external URL for the environment, while that could be changed whenever a real deployment happened.

We could improve the situation by introducing the URL in the job, so that the deployment should find the actual URL by checking the corresponding job rather than the environment.

I think we should probably also remove the uniqueness check for deployment to fix #26537 (moved). It doesn't really matter if two environments are sharing the same URL. It's just cache to the last deployment. There's little point to prevent a deployment from happening if the URL was already taken.

mentioned in merge request !11695 (merged)

Given the current status, I realized that we might need to pass the external_url from the environment if the job doesn't have a corresponding URL.

@godfat

I belive that you are right.

We are looking for code that basically does that:

CI_ENVIRONMENT_URL = options[:environment][:url].expand || environment.external_url

I believe that this is MVP for that:

diff --git a/app/models/ci/build.rb b/app/models/ci/build.rb
index 4b63557642..00245941bc 100644
--- a/app/models/ci/build.rb
+++ b/app/models/ci/build.rb
@@ -133,6 +133,13 @@ module Ci
       ExpandVariables.expand(environment, simple_variables) if environment
     end
 
+    def expanded_environment_url
+      url = self.options.fetch(:environment, {}).fetch(:action, 'url') 
+      return ExpandVariables.expand(url, simple_variables) if url
+
+      persisted_environment&.external_url
+    end
+
     def has_environment?
       environment.present?
     end
@@ -486,6 +493,8 @@ module Ci
       variables << { key: "CI_COMMIT_TAG", value: ref, public: true } if tag?
       variables << { key: "CI_PIPELINE_TRIGGERED", value: 'true', public: true } if trigger_request
       variables << { key: "CI_JOB_MANUAL", value: 'true', public: true } if action?
+      variables << { key: "CI_ENVIRONMENT_NAME", value: expanded_environment_name, public: true } if expanded_environment_name
+      variables << { key: "CI_ENVIRONMENT_URL", value: expanded_environment_url, public: true } if expanded_environment_url
       variables.concat(legacy_variables)
     end

In next iteration, I would probably do a separate service/presenter to encapsulate variables rendering for a build.

closed via commit f7110642

closed via merge request !11695 (merged)

mentioned in commit maxraab/gitlab-ce@f7110642

marked this issue as related to #32829 (closed)