I tried commenting out some lines from a .gitlab-ci.yml file and the pipeline is failing saying the YAML is not properly formatted.
Below is the picture of what I see in the GitLab CI-Pipeline UI.
Below is the .gitlab-ci.yml file that is error.
stages:
- build
- test
# - release
build-demo-commands:
extends: .npm-job
stage: build
script:
- npm run build-demo-prod
include:
- project: 'myproj/gitlab-ci'
ref: '1.2.0'
file: 'templates/npm.gitlab-ci.yml'
# - project: 'myproj/gitlab-ci'
# ref: '1.2.0'
# file: 'templates/Kaniko-npm.gitlab-ci.yml'
I suspect that there is a pre-processor for the CI-pipeline which supports a comment syntax.
What is the correct way to comment out lines in a .gitlab-ci.yml file?
Searching for answer
I found this Add comments to .gitlab-ci.yml, which was merged two years ago. Now I just need to find the page that says how to do it!
https://docs.gitlab.com/ee/development/code_comments.html - not helpful
https://docs.gitlab.com/ee/development/cicd/templates.html#template-types -
https://docs.gitlab.com/ee/development/cicd/templates.html#explain-the-template-with-comments - Looks like the answer so why does it complain?
https://blog.wplauncher.com/add-comments-to-yaml-file/#:~:text=In%20order%20to%20add%20comments,line%20in%20a%20YAML%20file. This says the # is the way to do comments.
EDIT/UPDATE:
I believe the problem is with the included scripts and not with adding the comments. When I removed the comments I still got an error. The error was:
Found errors in your .gitlab-ci.yml:
npm-deploy-snapshot job: chosen stage does not exist; available stages are .pre
build
test
.post
You can also test your .gitlab-ci.yml in CI Lint
So I now believe that using the hash (#) character is the correct way to comment a .gitlab-ci.yml file.
Comments in YAML use a # character which comments out the remainder of the line
Wikipedia says:
Comments begin with the number sign (#), can start anywhere on a line and continue until the end of the line. Comments must be separated from other tokens by whitespace characters.[16] If # characters appear inside of a string, then they are number sign (#) literals.
Related
In our gitlab-ci.yml file, we have include reports in our testing stage from cobertura.
The yml worked fine up until a few days ago, and although literally nothing has been changed on the yml file, it is now being rejected as invalid.
The error is Property cobertura is not allowed.
Since nothing has changed in our code, i'm wondering if there is an update on gitlab maybe or if there is a setting i need to change that someone may have altered by accident.
Not sure if it's helpful, but here is the error on gitlab..
Thanks for any help!
As it was mentioned, the artifacts:report:cobertura has been deprecated. You can replace the
cobertura: backend/coverage/cobertura-coverage.xml
with the following:
coverage_report:
coverage_format: cobertura
path: backend/coverage/cobertura-coverage.xml
If you're on GitLab 15.0, artifacts:report:cobertura has been deprecated and replaced by artifacts:reports:coverage_report.
Reference: https://docs.gitlab.com/ee/update/deprecations.html#artifactsreportcobertura-keyword
I am doing the DBT hello world tutorial found here, and I have created my first project on a windows machine. My profiles.yml file looks like this:
my-bigquery-db:
target: dev
outputs:
dev:
type: bigquery
method: service-account
project: abiding-operand-286102
dataset: xxxDBTtestO1
threads: 1
keyfile: C:\Users\xxx\.dbt\abiding-operand-286102-ed9e3c9c13cd.json
timeout_seconds: 300
when I execute dbt run I get:
Running with dbt=0.17.2 Encountered an error while reading profiles: ERROR Runtime Error
dbt encountered an error while trying to read your profiles.yml
file.
Profile my-bigquery-db in profiles.yml is empty
Defined profiles:
my-bigquery-db
target
outputs
dev
type
method
project
dataset
threads
keyfile
timeout_seconds
Any idea?
At first glance from both your code and the source walkthrough, this is just a yml config problem. YML is a markup language that is white-space sensitive. And by just looking at the example that you may have pulled from - it doesn't look appropriately white spaced to me.
I'm not sure if you can simply copy from the below but it might be worth a shot.
my-bigquery-db:
target: dev
outputs:
dev:
type: bigquery
method: service-account
project: abiding-operand-286102
dataset: xxxDBTtestO1
threads: 1
keyfile: C:\Users\xxx\.dbt\abiding-operand-286102-ed9e3c9c13cd.json
timeout_seconds: 300
Basically - your dbt profile.yml needs to be setup with the sections at certain levels (not unlike python indentation or any other white spacing scheme).
This problem only happens with Laravel 5.8 on my shared hosting.
It is working fine in my shared hosting with Laravel 5.7.
It is working fine in my local environment with Laravel 5.8.
the problem is:
every time I run php artisan commands (on my shared hosting with Laravel 5.8 only) I got this error
The environment file is invalid! Failed to parse dotenv file due to an invalid name.
Failed at [APP_NAME].
my .env first line is : APP_NAME=rased
Also my site after updating to Laravel 5.8 is becoming a white blank page!
This is a general error related to parsing the .env file.
You'll see this is indicated in the error e.g.
The environment file is invalid!
Failed to parse dotenv file due to unexpected whitespace.
Failed at [This will fail].
In this example it was caused by having unescaped whitespace in the APP_NAME field i.e.
APP_NAME=This will fail
To fix, escape with quotes e.g.
APP_NAME="This is better"
This is general Error when we change our app name. To remove this error just do this.
APP_NAME=My Project Name
to this
APP_NAME="My Project Name"
You just need to add "" course around name.
Thanks
I found the cause of this problem.
It was because of line separator in .env file !
It must be CRLF not LF
My .env file was LF
see the screenshot to understand the solution
I received a similar error while upgrading from Laravel 5.5 to Laravel 5.8.
The environment file is invalid! Failed to parse dotenv file due to an
invalid name. Failed at [//APP_ENV].
5.5 would accept C style comments on APP_ENV:
// env file setup for production environment
//APP_ENV = production
//APP_DEBUG = false
// env file setup for local environment
APP_ENV = local
APP_DEBUG = true
While 5.8 will not. # works for comments:
# env file setup for production environment
#APP_ENV = production
#APP_DEBUG = false
# env file setup for local environment
APP_ENV=local
APP_DEBUG=true
I had tried removing the spaces as a brand new 5.8 application installs without spaces in these definitions. That didn't fix it.
Curiously I still have C style comments other places in the file, so only for APP_ENV?
I changed the encoding of .env and it was solved.
UFT-8 without BOM
Thanks
I recently ran into this same problem on my app for Laravel 6.12.0.
I was able to resolve this issue by adding a blank new line/space at the top of the .env file.
Example .env file:
[add a new line here]
APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost
LOG_CHANNEL=stack
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=
BROADCAST_DRIVER=log
CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS=null
MAIL_FROM_NAME="${APP_NAME}"
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=
PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1
MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
I had exactly the same problem, but a different solution. CRLF made no difference.
This was driving me nuts, and I read somewhere that C style comments were no longer supported. My env file didn't contain any, but in desperation I added the following line to the top of the file:
# getting tiresome.
I don't think the wording is important, but the key thing was there was a comment.
After that, it worked. I don't know why, but it did.
Fast forward a few months, and the problem returned the next time I have to upgrade Laravel. This was kind of weird as the file was the same. This time I had to make sure I saved the file as UTF-8 without BOM.
I have added course "" around the DB_DATABASE path.
MAIL_FROM_NAME=Account confirmation
i was just making spaces between the two words
Just try to avoid it like : Account_confirmation
MAIL_FROM_NAME=Account_confirmation (correct)
In my case, I had an extra line that shouldn't be there.
Header set X-Frame-Options SAMEORIGIN Removed this and IT WORKED
I discover that if you declare the APP_NAME in quotes in the .env file, It will allow spaces in the app name but make sure you restart the server using the command (php artisan serve)
For e.g: APP_NAME='Laravel Login'
That works for me.
delete the .env file and recreate another with the same content
In case anybody else gets here and hasn't solved their problem. I came across this issue and found that it was due to using a hyphen to separate the environment variable name.
NOM-OPEN="2020/01/24"
This was okay up to Laravel 5.7 but fell over for 5.8. To solve it change the hyphen to an underscore.
NOM_OPEN="2020/01/24"
Don't forget to update all references to the variable!
I'm experiencing problems with HTML formatter and the output_path in behat. I'm using cmd:
behat --format=html --out=output.html --config /www/config/behat.yml test.feature
Simplified config (behat.yml) looks like this:
default:
formatter:
name: html
parameters:
output_path: /www/features/output
The problem is that no matter what output_path I set, the output.html is always placed inside same directory, where is behat.yml (/www/config). Can anybody see what am I doing wrong?
Thanks a lot for help!
UPDATE Behat v 2.4.3 use the output dir same as current dir (not the same as config), but still output_path parameter in behat.yml seems not working.
consider using the command line args and see if the issue still happens
for example:
/bin/behat --config=/pathToYML -f pretty,progress,junit --out path/to/output/file/for/pretty,,path/to/junit/output/file /path/to/behat/features/folder
The command line stuff seems to want all three if you don't specify something it will output to console which is why there are , , between pretty and path
This could hold a clue as to why you are having a problem if the command line wants more than one option by default you might need to configure your yaml for that as well.
Our shell script just feeds the command line what we want dynamically instead of doing guess work with yaml configs. Good luck
I had the same issue with behat 2.4.0, this was a known bug that was fixed on version 2.4.3.
Installation method #2 (PHAR) in the guide unfortunately only gives you version 2.4.0 at the time of writting... So in order to fix this you'll have to use the composer method #1.
Hope that helps!
Whilst doing git svn clone -s https://svn.example.com/repo/ I received the following output:
r3073 = a6132f3a937b632015e66d694250da9f606b8333 (refs/remotes/trunk)
Found possible branch point: https://svn.example.com/repo/trunk => https://svn.example.com/repo/branches/v1.3, 3073
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
fatal: Not a valid object name refs/remotes/tags/Sync Controllers
cat-file commit refs/remotes/tags/Sync Controllers: command returned error: 128
Running git branch -a gives:
remotes/tags/Sync%20Controllers
remotes/tags/v1.1
remotes/trunk
remotes/v1.2
I think the problem is that "remotes/tags/Sync Controllers" != "remotes/tags/Sync%20Controllers".
The tag on SVN has a space in it, but the tag in git had this space converted to %20 (URL encoded). To solve it just manually add a new tag with the verbatim name:
cd .git/refs/remotes/tags/
mv Sync%20Controllers Sync\ Controllers
Then run the git svn clone command again.
(Normally you'd do this with git tag OLDTAG NEWTAG but git was not allowing me to define a tag with a space in. The tag files are simply text files containing the hash of the relevant commit.)
You may use git-svn server-side alternative, SubGit in order to avoid many of git-svn translation problems.
I'm a SubGit developer and could say that we worked a lot to resolve character translation issues like the one above; in this particular case tag would be translated to a refs/tags/Sync+Controllers tag.
Note also, that git-svn has translated Subversion tag as a branch instead of a tag.
I ran into this issue today, and considered this branch which contains a pace in it is not important, i just run
git branch -r -d partialPayment%202.4
And re-run git svn fetch
It skipped current branch and continue grabbing the next one.
I'm using git 1.29.2 and getting the issue too. Additionlly it is running into a Windows Server 2016 and git is under cygwin.
Was checking into /GitMigration/.git/svn/refs/remotes/origin, and the folder is there with blank spaces not %20 so nothing to change on it.
However into the packed-refs the tag that is producing the problem does not appears, no name and no hash.
The problem should has another related issue with something else that produce the error, not just this.
Looking into the ./.git/config found a series of repetitions of the following lines:
branches = server/branches/*:refs/remotes/origin/*
tags = server/tags/*:refs/remotes/origin/tags/*
That are producing each time i did run the git-svn clone sentence. So i did remove those from the config file, save it and run again, but this time using git svn fetch, to prevent get again the lines duplicated, and voala !! Problem solved.
I believe the problem with spaces is fixed in Git >= 1.8.0 (See: #786942).
So you should upgrade it.
I've tested it and it seems to work in the recent version of git.
See GitHub Home page: https://github.com/git/git