4

It seems to me that you're looking for an artifact store such as Nexus or Artifactory. Both solutions have Jenkins plugins which will simplify the process of uploading your artifacts to them. You can find an example as to how to upload artifacts from your Jenkins pipeline to Nexus in this link and an example for Artifactory in this link. Both solutions are ...


3

I highly recommend using npm ci instead of npm install. The slow part of installing npm modules is figuring out everything that needs to be installed. If you commit your package-lock.json and use npm ci, it skips that part entirely and just looks at your lockfile to download what's needed. It's significantly faster.


3

Are you sure that your registry is publicly available? Checklist: Check if the domain is reachable and responding the right IP address -- nslookup myregistry Check if your port is open or not blocked any kind of software (let's say via firewalls or AWS security group) -- telnet myregistry 5050 Check if your registry is not restricted for a particular CIDR ...


2

Assuming a docker file like this... FROM ubuntu:18.04 ARG TF_VERSION=0.12.25 RUN apt-get install wget -y RUN wget -O terraform.zip https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip In your GitHub action you would need to get the current version from your Dockerfile. export CURRENT_TF_VERSION=$(grep -Eo '[[:...


2

Combining the answer of https://devops.stackexchange.com/a/3854/10932 and the comment of Overbryd along with a slight modification worked for me. Here, instead of using using git remote set-url command, I used git remote add. The code will look like this: image: maven stages: - build - deploy - tag maven_build: stage: build script: - mvn clean ...


2

What you need is not to checkout both projects side by side, but to add the library as a Git submodule in your application repository. Then set up GitLab CI to checkout submodules before build. This will not only make your CI work, but as an added benefit each commit from application repository will reference a specific commit from library repository, so ...


2

Maybe solving space problem first. Then, in my opinion, I prefer using rsync for copy file to server.


2

I've seen it done before but wouldn't call it common. There are other artifact servers, and many git repositories have the concept of a release with artifacts that makes more sense. I suspect Docker Hub is one of many artifact servers to introduce rate limits and other usage caps, so if you do this, make sure you control (or pay for) the registry server. ...


2

Your use case is very simple, so relying on GIT_STRATEGY=fetch is probably sufficient and as you said the default behavior. You should be cautious using artifacts unnecessarily as they are uploaded to the gitlab server. The answer to your question generally depends on a few things, like the size of your repository, network connection, runner executor type, ...


2

This is likely because your requests were dropped before they landed on the GitLab host. Check your firewalls and other security rules after assured that the 1234 port is open


1

Please refer to the following article on the SonarQube - SonarScanner setup best practices. It will be good if the following hardware recommendations are considered for the SonarQube installations. Following are some of the important considerations. SonarQube server should be on a real DB not on H2. The analysis should occur very close to the SonarQube DB.


1

This is a plugin that you can install. Plugin Name: Build Pipeline Plugin Web page: https://plugins.jenkins.io/build-pipeline-plugin/


1

A bit too long for a comment, so converting to an answer: That's super broad and highly depends on your final needs IMHO, if you're full AWS and ok with being vendor locked down, then code commit/code build/code pipeline is great as it's nicely integrated now. If you have needs outside pure AWS services, that may get harder, for exemple if you plan on ...


1

Your error is most likely from referencing the wrong directory in your script block of your job. When GitLab executes your job in a container, it mounts the project directory to the /builds directory in the container. You can reference this either by specifying /builds/scheduler-deployment.yaml or by using the predefined environment variable $CI_PROJECT_DIR ...


1

Yes, you can use the rules syntax. You can use this in combination with regex for commit message, ci_pipeline_source or any other available CI variables. job1: script: - do something on schedule only rules: - if: '"$CI_PIPELINE_SOURCE" == "schedule"' when: always job2: script: - runs on Merge request pipeline ...


1

In my opinion there should be a staging branch , which holds the production candidate code.And instead of a Test env , have a staging env which will be complete replica of Prod env. In the Staging env the QA can perform their testing and other checks. Dev env = only for developer. Stage env = Replica of Prod and holds production candidate build/code , ...


1

Okay, found it. It seems the .gitlab-ci.yml hidden job needs to have a "script:" to solve the problem. See below: .gitlab-tf-backend: &gitlab-tf-backend script: - export TF_ADDRESS=${GITLAB_API_ENDPOINT}/projects/${CI_PROJECT_ID}/terraform/state/${STATE_NAME} - export TF_HTTP_ADDRESS=${TF_ADDRESS} - export ...


1

You could use dynamic child pipelines. (https://docs.gitlab.com/ee/ci/parent_child_pipelines.html#dynamic-child-pipelines). You could create a job for triggering your job "buildArtifact" in a yml-file created with jsonnet in your "checkArtifactPresent". With using "--ext-str" or "--ext-code" in jsonnet. You can control ...


1

This can be achieved by running your build script in a docker container and applying your iptables rules inside that container, which won't affect the host runner's connectivity. For example, if the below script is executed in a GitHub Actions job (in the Ubuntu 18.04 GitHub shared runner), it will run the build script (docker_script.sh) in a debian docker ...


1

It appears the issue is in the URL used to access the documents in the blog post excerpt. First of all, the URL should begin with a / since the assets folder is at the root of the site project. However (and most importantly), I also had to add the baseurl to the file URL as shown below: blog post excerpt: <ul style="list-style-type:none"> ...


1

I switched to using a production build for testing by use of a local webserver. I leveraging the [jest-puppeteer][1] library which allows you to start a webserver with your tests. jest-puppeteer.config.js /** * find all flags at the following site @jkr * https://jestjs.io/docs/en/cli */ module.exports = { launch: { devtools: true, // allows ...


1

You can specify that you want gitlab to execute your CI job on a windows machine using tags. Gitlab made Windows Shared Runners available as Beta in Jan 2020. Their announcement shows how to use the tags key in your .gitlab-ci file to specify Windows machines. You can also run in a docker container in windows: https://docs.gitlab.com/runner/executors/...


1

Periodicity will only come into effect if the overall integration and deployment processes take a long time to complete, which is more likely the actual problem. Said differently, in an environment where applications are built using lightweight architectures that are quickly scanned, built, deployed and tested, periodicity would cease to be relevant. I ...


1

This is indeed a tricky thing to do "right", because there are so many moving parts. I have found that it helps to reduce the degrees of freedom by adopting some conventions, and factoring out some parts. Draw a line between where Terraform is responsible and where Ansible becomes responsible, and separate those stages. You do this so that you can deal with ...


1

You are right about Terraform having a plan-apply cycle which may not be that conducive to automation. The following has worked for me in similar situations: Use Terraform to "develop" new versions of a base EC2 image. Use Ansible playbooks to provision EC2 instances off a specific version of the image and run tests on them.


1

Jenkins supports scripted pipeline which can handle my every requirement. Buildbot can handle these requirements with custom steps, i suppose, but it's too hard if compared to Jenkins' scripted pipeline.


1

So, I actually ended up with the following strategy. I separated the charts from the source code. Basically, I have a repository that tracks all the helm charts only Why? I wanted to have a repository representing my cluster(s) so it's easy to rebuild a cluster from it I also wanted to keep track of the current version deployed. Basically, this repository ...


1

Approach you are describing - where app version is substituted at helm upgrade command - is pretty popular as well. Maybe it's not well documented - I'm not sure about that. Yet another approach that people use is doing helm template which would compile everything (including variable resolution) into fixed k8s definitions and then doing GitOps on that. ...


1

Keep learning other requirements for devops engineering. such as: Operating System concepts (Process management, threads and concurrency, POSIX basics, I/O management, file systems, memory storage, ...) as a devops engineer you need to know everything about the operating systems and how they work. to know everything about the operating systems, first you ...


1

I would suggest adding a job that checks changes in the latest commit and build only that service where some files have been changed.


Only top voted, non community-wiki answers of a minimum length are eligible