Gitlab CI variables returns empty string?

Question

It's been 2 days since one of my project' build starts failing on Gitlab CI. The main error was E_MISSING_APP_KEY and when I check another variable just by echoing $HOST and $PORT from my .gitlab-ci.yml config, like this

tests:
  script:
    - echo "${HOST} ${PORT}"
    - node -e "console.log(process.env.HOST, process.env.PORT)"
    - node_modules/.bin/nyc node ace test -t 0

I got nothing.

The build was failed because it can't read my environment variable that I set on its CI Settings.

Anyone experiencing same issue? & how to solve this?

---

Update:

I'm trying to create new project with only containing .gitlab-ci.yml file here and it's seems working just fine

But why the world it's still failing on my main project?

Awl

Have you tried any of the steps outlined at the "More details" link? – Notarize

The "More details" link is actually built-in "exception message" from Adonis.js frameworks & the errors has nothing to do with it. – Awl

Maybe I misunderstood your question. You said the E_MISSING_APP_KEY error is thrown, and that "more details" link provides info about the E_MISSING_APP_KEY error. How is that not relevant? – Notarize

Edited, apologize about that.. – Awl

I see, so you've entered the variables into the CI's settings but adonis can't seem to access the APP_KEY. Is it accessible from process.env? – Notarize

Yes, but as you can see on my first image. echo "${HOST} ${PORT}" also not working. – Awl

Answer 1

The issue is solved by delete all of my variables I've had & set them back from the CI Setting. And the build pipeline is running without any errors. (except the actual testing is still failed, lol)

Honestly, I'm still wondering why this could happened? and hopefully no one will experiencing same kind of issue like me here..

Awl

Answer 2

For anyone else having a similar problem:

check your variable, if it is protected your branch has to be protected as well or remove the protected option on your variable

Docile

Dude, thank you. This was a key point that I missed and fixed my issue immediately. – Gurango

My branch is protected, I unprotected the variables and still got this issue fixed. – Anarthrous

Bingo Boom Shakalaka!! – Radferd

Answer 3

If you are running the job on tag creation, you have to protect the tag. To do that automatically, you can give it a pattern to Gitlab in order to protect it. If you think anyone should be able to create a tag, then better to unmark the protected option for the variables.

From Gitlab docs:

To protect a tag, you must have at least the Maintainer role.

1. Go to the project’s Settings > Repository.
2. From the Tag dropdown list, select the tag you want to protect or

type and select Create wildcard. In the screenshot below, we chose to protect all tags matching v*

You can protect only giving maintainers permission to create a tag pattern, for instance.

From the Allowed to create dropdown list, select users with permission to create matching tags, and select Protect

Felipa