11

As you guessed, build not necessarily means "compile". Building is a process of creating software from sources, which might include stuff like gathering dependencies, compiling, archiving, transforming code in any way, but also testing, deploying to different environments and promoting the artifacts between them.


8

Based on the comments to my question, and some basic testing the following seems to work: Use nested parallel statements. (Thanks @lawnmowerlatte) Although today (May 15th 2017) Jenkins Blue ocean does not visualise this properly. Possible solutions discussed here


6

I'm not overly familiar with Docker particularly but it sounds a lot like issues one would get when building a normal .NET application or java app with the need to store their external dependencies (DLL or jar). To solve this I'm quite fond of artifactories. Two of the most popular are sonatype's Nexus and JFrog's Artifactory. Both offer a free Open Source ...


5

It depends on the artifact repository you are using but in general, you tag the artifacts in the repository to indicate their state. This can specify it has passed some level of quality gate, some approval, or what ever is required to move through the stages. I would say you tag the artifact as to it's state, not move between artifact repositories. A ...


4

You might want to explore immutable architecture. Steps CI with static analysis(Sonarqube, because free!), pushing version artefacts to Nexus. Base Image using Packer. These must be revisited from time to time. Base Image has security hardening, log shippers, monitoring tools etc. Environment/Application specific images from Base image. healthCheck and ...


4

Specifically in answer to your 3rd question, if you are willing to look outside of the Jenkins Ecosystem there are alternatives out there that might be of value to you. For my clients who use the Microsoft Stack and have fewer than four teams, I have been recommending the use of AppVeyor it is highly tuned for the .NET Stack and integrated very naturally ...


4

Well, you can pass multiple goals to maven in command line simply by passing them as arguments. Skipping test require a java system property that you can also pass as an argument to the command line. For packaging a maven artifact, executing a sonar analysis with the maven goal but skipping executing the tests you should use : mvn package sonar:sonar -...


4

I had a similar situation in which I wanted to nest other parallel jobs threads inside another parallel one. This code worked for me: def performDeploymentStages(String node, String app) { stage("build") { echo "Building the app [${app}] on node [${node}]" } stage("deploy") { echo "Deploying the app ${app}] on node [${node}]" ...


4

I have actually solved the problem by cloning repository directly in codebuild: Pass GitHub token: - { Name: GITHUB_TOKEN, Value: {Ref: GitHubToken } } - { Name: GITHUB_BRANCH, Value: {Ref: GitHubBranch } } # Execute git clone in install step: - git clone --single-branch --depth=1 -b $GITHUB_BRANCH https://gitorgname:$GITHUB_TOKEN@...


4

We've had exactly the same problem - our build stage needs to use information from two separate locations. To solve this in a generic manner, I've created two general purpose Lambdas - one that will merge artifacts, and one that will extract specific files from an artifact. In both cases a new artifact is created that can be passed on to a subsequent ...


3

This discussion gives a pretty good suggestion on how to accomplish what I want. https://discuss.circleci.com/t/does-circleci-2-0-work-with-monorepos/10378/11


3

There is currently an issue open to share Gradle cache between containers: https://github.com/gradle/gradle/issues/851 I think the best solution at the moment is to bake as many dependencies in to the Docker image as possible, and then use a volume to share between sequential builds, limiting it to one concurrent build per host. You can mount the cache on ...


3

Problems with golden images are that you have to store a full system image with overhead of data which is not build-specific, and using conventions for configuration to make deploy process the same for all versions. TL;DR: Infrastructure as a Code, version-specific storage for data outside the app package. The problem is easily solved by storing config ...


3

Any organization that needs the level of control you've specified is essentially forced into the preapproval process ("walled garden"). It's a pain for developers, but it's a necessary process to keep the company safe. I've even heard of companies with programs that scan all their workstations regularly to find and remove unapproved software. It's worth ...


2

Pipeline as Code (PaC) means that the CI/CD configuration will be stored in the VCS instead of in the CI/CD tool itself, e.g. configuring it manually by using a UI. Any experiences what can be the "critical mass" where this investment is a clear pay-off and not an overkill? Imagine that more than 100 jobs have been configured manually the last couple ...


2

There are enterprise tools that manage these opensource dependencies namely Jfrog Artifactory with the Xray feature and Inedo ProGet with features for license filtering and vulnerability scanning. Basically, allows you to restrict or permit download of package so companies can set policies to ensure development isn't breaking rights of use or building ...


2

Currently my team uses Jira, and it's RapidBoard agile thing. We aren't using real agile, but it's nice to schedule work loads for the next week. Jira can be super complex, but we Have our tickets set up to: New -->InProgress -->Done +-> Won't Do It can be linked to github or to Bitstream, etc. which is nice. If you want more complex code ...


2

The answer is: it depends. Before I answer, I need to provide definitions for a couple of terms to prevent ambiguity. 1) Deploy is defined as the act of changing executables in an environment. This might mean that new source is copied over, and some process is restarted. Or a new version of a docker container is placed into an orchestrator - doesn't really ...


2

I managed to setup an environment that does what I described above. Here are the full details: Launch a template that creates a CodeCommit repository for the application. This repository will be used to store both the source code and the CloudFormation (CF) templates to create the required infrastructure for the application; Launch a template that creates a ...


2

As this question is quite high-level, I give a high level answer. Technically, if there is an incident, you would normally enforce a shutdown of a running container and a replacement with a newer image with an implementation of the change request resulting from the incident. How much automation will be possible to get there, I think it really dependends on ...


2

Yes, there is: If your commit message contains [ci skip] or [skip ci], using any capitalization, the commit will be created but the pipeline will be skipped. Alternatively, one can pass the ci.skip Git push option if using Git 2.10 or newer: git push -o ci.skip From: GitLab CI YAML documentation - "Skipping jobs"


1

I would look into Azure Functions. Create a gate trigger and enable azure function after a successful release. References: https://docs.microsoft.com/en-us/azure/devops/repos/git/create-pr-status-server-with-azure-functions?view=azure-devops


1

On building the docker image, you need to have the docker daemon enabled. You can also use the jib, a Google project, which creates images for your Java applications without the Docker daemon


1

You need to use continuous deployment tools. Not available yet.


1

You can separate the steps, especially as it would let you do divide the work among different agents. You can also leave them in a single agent if you wish. The primary advantage I see is leveraging different pools for different sets of work. With releases last I checked variable scope was limited (as of 2018) to the "phase". I wouldn't necessarily ...


1

Do not trigger Build 2 automatically from Build 1. Instead add a last step to Release 1 to queue Build 2. There are a few ways to do it, e.g. https://stackoverflow.com/questions/52821204/how-to-queue-build-pipeline-as-task-from-release-pipeline


1

Welcome to devops.stackexchange.com. What works best is dependent upon the team. Find a good tool for the team and perhaps change that when the circumstances change. Also you might do a little thinking ahead to work out what approach might be best fit for the near future (e.g., will my team expand? will my number of servers expand? will I have a security ...


1

There are now two possible solutions: One NPM only one, and a clean one. First the NPM One (where im not quite sure what exactly will work): I just googled "npm deployment" and found 3 different Plugins which do exactly that what you want ( 1, 2, 3) and there are many more. Which now you suits you best, will be your choice. Now the cleaner one (because we ...


1

As of Sep 4 2018 Amazon added support for multiple input sources: https://aws.amazon.com/about-aws/whats-new/2018/08/aws-codebuild-adds-ability-to-create-build-projects-with-multiple-input-sources-and-output-artifacts/ From documentation: { "name": "sample-project", "source": { "type": "S3", "location": "bucket/sample.zip" }, "secondarySources": [ { ...


1

In my opinion, there should always one key per user: Security: If an employee will leave the company then the key could be revoked and the person who left the company cannot trigger builds anymore Access-control and responsibilties: developers from team b are allowed to deploy apps to the production environment of team b, while members of team a are ...


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