How to change the build email template in Gitlab CI - gitlab-ci

How to change the default build email template in Gitlab CI.
From Below we can send email.
https://docs.gitlab.com/ce/project_services/builds_emails.html
But I have to change the default email template in Gitlab CI.
Thanks in advance

Related

GitLab CI/CD for vue.js application and Node API

how to edit the .gitlab-ci.yml file in order to correctly execute the CI/CD pipeline on behalf of a vue.js application?
A .gitlab-ci.yml should be part of your repository, at the root folder of said repo.
See for example "How to use GitLab CI/CD for Vue.js" (2017, so some details may have changed since then)
Or the 2020 "How to auto deploy a Vue application using GitLab CI/CD on Ubuntu 18.04"
In both case, you can directly edit the .gitlab-ci.yml, add, commit and push.
Create a .gitlab-ci.yml file at the root of your repo.
GitLab will check for this file when new code is pushed.
If the file is present, it will define a pipeline, executed by a GitLab Runner.

GitLab upload npm package with dynamic package.json informations

I want to upload an npm package to a local GitLab instance.
According to the GitLab documentation, it is necessary to provide the package name with the namespace and to include the entry publishConfig in the package.json.
As soon as I do this manually and create a valid .npmrc file, the upload works.
Is there a possibility to add this information dynamically to the package.json via the yml file for the CI? All the necessary information is available as predefined environment variables.

GitLab Default Issue Template for all new Projects

I'm wondering if there is a way to set a default issue template for all new created projects? As a developer I often create new projects for every job I take. What I already have done is creating a default project template from which I create my new projects. So all the settings are always the same and I do not have to set the project up again from the scratch.
What I am missing is the part, where I can define default issue templates for all my projects, as the issue template is always the same, too. I know I can create a issue template for my projects by adding them to the issue-template directory in my repository. But how can i 'automate' this, to not have to add them manually?
Can anyone help me out?
Greets
Thomas
2020: The notion of template repository is only for GitLab premium.
Locally, you could define (git init --template) a template repo that would:
be used for any new repository
include your standard issue template file
be pushed to your new GitLab repo.
Update 2022, for all GitLab tier:
See GitLab 14.8 (February 2022)
Add default issue and merge request templates in a project’s repository
In addition to defining default issue and merge request description templates in project settings, you can now set default templates in the .gitlab
directory of a project’s repository.
Do it by creating a Default.md file in the issue or merge request templates folders.
If default templates exist in both the project’s settings and in the repository, the template in the settings
takes precedence.
Thanks for the contribution #davebarr!
See Documentation and Issue.

Configure SourceTree with Gitlab SSH

I've already trying to set gitlab few days with SourceTree , you can explain it step by step? I can not find the solution.
Bye and thanks!
It is pretty straight forward.
Go to File -> New / Clone and it'll bring to the front the SourceTree repo info where you can add new repos.
Click New Repository and then Clone from URL
Enter the URL of your GitLab repository, and below it the location where you want to save this repo on your computer and name of the repository if you want to name it differently.
A window will popup asking ask you for your GitLab username and password
And that's it. The GitLab repo will be cloned.
In case you are wondering where you get your project's URL on GitLab, it looks like this on GitLab when you click on your project:

Using secret api keys on travis-ci

I'd like to use travis-ci for one of my projects.
The project is an API wrapper, so many of the tests rely on the use of secret API keys. To test locally, I just store them as environment variables. What's a safe way to use those keys on Travis?
Travis has a feature to encrypt environment variables ("Encrypting environment variables"). This can be used to protect your secret API keys. I've successfully used this for my Heroku API key.
All you have to do is install the travis gem, encrypt the string you want and add the encrypted string in your .travis.yml. The encryption is only valid for one repository. The travis command gets your public key for your repo and can then decrypt the string during the build.
gem install --user travis
travis encrypt MY_SECRET_ENV=super_secret -r my_username/my_repo
This gives you the following output:
Please add the following to your .travis.yml file:
secure: "OrEeqU0z6GJdC6Sx/XI7AMiQ8NM9GwPpZkVDq6cBHcD6OlSppkSwm6JvopTR\newLDTdtbk/dxKurUzwTeRbplIEe9DiyVDCzEiJGfgfq7woh+GRo+q6+UIWLE\n3nowpI9AzXt7iBhoKhV9lJ1MROrnn4DnlKxAEUlHTDi4Wk8Ei/g="
according to this in travis ci documentation it's said that :
If you have both the Heroku and Travis CI command line clients installed, you can get your key, encrypt it and add it to your .travis.yml by running the following command from your project directory:
travis encrypt $(heroku auth:token) --add deploy.api_key
refer to the following tutorial to install heroku client according to your OS
You can also define secret variables in repository settings:
Variables defined in repository settings are the same for all builds, and when you restart an old build, it uses the latest values. These variables are not automatically available to forks.
Define variables in the Repository Settings that:
differ per repository.
contain sensitive data, such as third-party credentials.
To define variables in Repository Settings, make sure you’re logged in, navigate to the repository in question, choose “Settings” from the cog menu, and click on “Add new variable” in the “Environment Variables” section.
Use a different set of API keys and do it the same way. Your travis box gets setup for your build run and then completely torn down again after your build has finished. You have root access to your box during the build, so you can do whatever you want with it.