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.
Related
I've been trawling documentation on Netlify's site for how to deploy a node application (specifically a Vue application) which has a private npm repository as a dependency.
I have an .npmrc file setup as follows:
//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}
#my:registry=https://npm.pkg.github.com
I also set the GITHUB_TOKEN variable in my build process's environment variables to the correct value.
However, the build fails.
There is an outline of how to achieve a successful build with a private Github package repository here: https://docs.netlify.com/configure-builds/repo-permissions-linking/#npm-packages.
However, it's still unclear as to what I need to do specifically to both my package.json file and also how to configure the build process' environment variables ...
Could anyone show me a full working example which doesn't leave me scratching my head?
Do I add:
"package-name": "git+https://<github_token>:x-oauth-basic#github.com/<user>/<repo>.git"
to the dependencies section of the package.json?
If yes, how do I then hide my <github_token> and provide the build process with this in Netlify?
How do I also get the same process working locally?
Why can't Netlify just inject the GITHUB_TOKEN into my .npmrc file so I have parity with my local development environment?
It is really good that we have spinnaker pipeline as a code from roer and other tools. But is there a way that we will store these pipelines and as well as configurations on gitlab and restore by just fetching the files from gitlab? without really manually inserting the configurations?
You can use "Save Pipelines" stage.
See related commit for details.
I'm evaluating GitLab CI/CD at the moment and trying to get the pipelines working, however am having a simple(?) problem.
I'm trying to automate the build process by automatically updating ISO images. However these ISO images are not tracked by the repository and ignored in a .gitignore file. But this leads to the issue of when I try run make that it can't find the ISO image...
I'm just using a simple .gitlab-ci.yml file:
stages:
- build
build:
stage: build
script:
- make
And when I try running this in the GitLab CI interface, it clones the repository (without the ISO images), and then fails, as there is no rule to that make target (as the ISO images are missing). I have tried moving the files into the "build" directory which GitLab creates, however that gives the error of saying it has failed to remove ...
How do I use the local repository rather than having GitLab clone the repository to a "build" location?
You can't use Gitlab CI with the files that are on your computer, at least you shouldn't. You could do it with an ssh-executor that will login to a machine that stores the iso files (and it should be a server rather than your development machine) or you could have the docker executor pull them from ftp/object store. For testing purposes you can run the builds locally on your machine.
Right now, anyone that creates a branch in my project and adds a .gitlab-ci.yml file to it, can execute commands on my server using the runner. How can I make it so that only masters or owners can upload CI config files and make changes to them?
I'm using https://gitlab.com/gitlab-org/gitlab-ci-multi-runner running on bash.
The GitLab runner wasn't really designed for this scenario and thus you are unable to do this. What you could do instead is have a new project with just your .gitlab-ci.yml file and configure it so that it pulls the original repository. From there you can do all the other things you want to do with your repository.
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.