Each command in the Dockerfile is processed as a separate step. Every step from the build process gets executed in a dedicated container. It starts from Step 1 (the first command in the Dockerfile). That step is run in a container and if it is successful, a commit to a temporary image (let's call it image A) takes place. Then, Step 2 is executed in a ...
Frankly, if you go this route, you do not even need Ansible as a CI/CD driver. Ansible does not bring any infrastructure anyways, it just uses an existing ssh connection, so you can just use said ssh connection directly with your own scripts.
If the ultimate goal is to avoid any of the established solutions (Jenkins, Gitlab CI, whatever), then nothing ...
This is totally possible. Of course you can achieve it without jenkins or similar tools being required. We're always free to reinvent the wheel. The question becomes is it worth the effort? When it helps you avoid jenkins I'd be inclined to put the effort in. (I'd also suggest looking at Concourse before doing jenkins again, but that's not what this ...
This can be done through the Jrog CLI. The CLI has a recursive option that looks like it will do what you hope.
jfrog rt upload --recursive artifactory-mirror/* artifact-repo/dir-struct/
The CLI also has some performance improvements for uploads that doing it through curl or a browser don't seem to get. Also, scriptable!
You might use docker builder pattern. Briefly you need to create Dockerfile.build which adds pom.xml and run mvn dependency:resolve:
ADD ./pom.xml /src/pom.xml
RUN mvn dependency:resolve
Rebuild that image every time prior build. Docker will use cached image if ./pom.xml has not changed.
Docker 17.05 introduced 'multi-stage ...
Docker images are after all VM templates, i.e. they have to be more or less self-contained: you get the image, you run the environment with all the dependencies.
To approach the challenge operationally, Docker supports reuse of environments through the FROM statement i.e. you could maintain a base image and on top a much smaller image with the app itself.
The Docker client is a CLI interface to the dockerd REST API. Very little happens in the client itself. Docker performs build steps on the dockerd engine and changing this would be a non-trivial task. Each RUN step creates a temporary container to execute the command and gather the resulting container filesystem as a new layer. The build cache is maintained ...
I have a similar setup.
For feature/* and develop, I use something like 18.08-SNAPSHOT in my pom.
When we're ready to start release hardening, I'll cut a release branch (release/18.08) and change the version in the pom/s to 18.08.
I'll also bump the version on develop to 18.09-SNAPSHOT, for example.
From there, bugfix and finalise the release, merge to ...
In order Artifactory to cache your dependencies, you need to retrieve them from Artifactory. Once you use your virtual repository, which contains the Maven Central remote, Artifactory will download the dependencies from Maven Central and will cache them for the future use.
So, here's what you need to do in order to populate Artifactory with your ...
Welcome, Vivek 👋🏻
This is not how it works 😀
Your local cache (~/.m2) is not transferred to Artifactory if anything the direction is the other way around (in some point of time you'll see files from Artifactory appear in your local cache).
When you run a Maven build, the configuration you provided in Maven (check the Set Me Up button in Artifactory UI) ...
we now want to release faster
And from your comment:
Basically, since the artifacts depend on each other, we need to release them in the correct sequence. And since there's a lot of them, it takes some time.
I think you're having an X/Y problem. Yes, versioning plays a role, but it seems like you would benefit from solving the source of your problem ...
I figured out how to get this job to run which took a number of very specific steps:
1) The Maven3-Artifactory plugin will simply not do what I need it do here. I still need this in my job though to actually execute my custom maven plugin from the project POM. I configured the Build Environment for this plugin to NOT upload any build artifacts to ...
I got the answer on StackOverflow :
You can pass the xml file name as parameter to the maven test command. First need to change the pom file as follows.
I'm not an expert on this, but maintaining separate pom files seems like a recipe for things to get out of sync.
It would make more sense to define specific dependencies within the same pom.xml and execute them depending on specific goals or targets. I.e. -Pdev.
You could also then define a list of shared dependencies used by all targets (i.e. chrome ...