What i'm looking for is this kind of stack:
CI: Jenkins
Plugins: M2 Release, AWSEB Deployment Plugin
pom.xml version is 1.0-SNAPSHOT.
When i push to github, Jenkins creates a project-1.0-SNAPSHOT package and deploys it automatically on test server with AWSEB Deployment Plugin.
Once all devs are good on test server, I manually deploy on production the current snapshot with M2 Release and AWSEB Deployment Plugin.
pom.xml version on github is now set to 1.1-SNAPSHOT.
Does anyone has a similar stack, or has some usefull resources to do the entire chain ?
The AWSEB Deployment Plugin is just a focused version of beanstalker.
Actually, you can use something combining the maven-release-plugin (although I'd suggest using only versions instead) with beanstalker, like this:
http://www.nagaseyasuhito.net/2012/03/26/211/
Related
In our project, we are using maven as the build tool, GitHub actions as the build agent, and Jfrog as the artifactory to deploy the jar files. We have both snapshot and release versions (identified using the "SNAPSHOT" in the version tag in pom). Currently we use the maven deploy plugin to deploy the built artifacts to Jfrog and the details of the repository are configured in the maven settings using the following tags in the maven profile:
When running maven deploy, the deploy plugin builds the project and deploys it to the artifactory and respective repository based on the artifact's version (has "SNAPSHOT" or not). After going through a few documents and blogs such as the following one:
https://jfrog.com/blog/dont-let-maven-deploy-plugin-trip-you
we thought it was better to use the jfrog artifactory plugin to achieve this so that we can capture build info and all among others. Since we are using GitHub actions, I could not find an artifactory plugin that is used for GitHub actions (found one for Jenkins and a few others but not for GitHub actions), I also don't want to add the plugin to my pom file and configure the repository details there as it would tie the repository details in pom. Also, I would like to separate the deploy logic from pom and move it to a CI server, so that these details can be hidden from the developers (the maven deploy plugin does this somewhat as all the artifactory config happens in the maven settings file)
The artifactory plugin can be configured in pom as follows:
referenced from https://www.jfrog.com/confluence/display/JFROG/Maven+Artifactory+Plugin
Then I found that we can use Jfrog CLI in GitHub actions to deploy the artifacts, but I could not find how I can configure the CLI to use both snapshot and release repositories so that I do not have to manually decide where to upload them by using the repo name. Can anybody guide me on how to achieve this in CLI?
I have referred to the following links from GitHub as well as jfrog:
https://github.com/marketplace/actions/setup-jfrog-cli
https://github.com/marketplace/actions/jfrog-cli-for-artifactory
https://jfrog.com/blog/jfrog-cli-github-actions-hero
https://jfrog.com/blog/publishing-binaries-using-the-jfrog-cli
https://jfrog.com/blog/using-the-jfrog-cli-with-github-actions
https://www.jfrog.com/confluence/display/CLI/JFrog+CLI
SO, I have finally managed to figure out how this can be done using github actions.
Im my actions.yml file, I have added a new step which makes use of "jfrog/setup-jfrog-cli" action from the github actions marketplace, the link to this is as follows. It shows you how to configure the action.
https://github.com/marketplace/actions/setup-jfrog-cli
I have configured the artifactory platform url as well as the username and access token in this action.
A new action was created which would build my code using the "jf maven" goal. Before you can make use of maven using jfrog CLI, it needs to be configured using the "jf mvn-config" command, it is here that you can specify which are the release and snapshot repositories that you want to make use of. The following is the code snippet that I have used for the same. Please note that these are steps within the github actions pipeline job and not the completed build yml file'
- name: Setup jfrog
uses: jfrog/setup-jfrog-cli#v3
with:
version: latest
env:
JF_URL: "https://artifactory.com" #be mindful not to add the path /artifactory here as it will cause authentication issue
JF_USER: ${{ secrets.ARTIFACT_USER_ID }}
JF_ACCESS_TOKEN: ${{ secrets.ARTIFACT_TOKEN }} # You have an option of giving password as well
- name: maven build
run: |
jf mvn-config --repo-deploy-releases=${ARTIFACTORY_RELEASE} --repo-deploy-snapshots=${ARTIFACTORY_SNAPSHOT} # mention the names of your release and snapshot repos within the jfrog artifacory
jf mvn deploy
jf rt bp # (optional, deploy build info, use --dry-run flag to see the build info in console without committing it)
There are many other optional parameters which you can use to enrich and configure the build, it can be found in the following links
https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-RunningMavenBuilds
https://www.jfrog.com/confluence/display/JFROG/QuickStart+Guide%3A+Maven+and+Gradle
https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-BuildIntegration
I have a project being built with maven using TFS for source control and Octopus for deployment.
At the moment, I can perform a TFS CI build, create an octopus deploy package as a zip file from the output, and use octopus to deploy to my deployment target, extract the package and install the app.
What I would like to do is increment the version of the application projects when a new build is performed (perhaps nightly).
Is the correct way to do this, to get my build server to set the new version on the project, using mvn versions:set -DnewVersion=x.y.z then to run mvn deploy to push the updated packages to the networked repository. Then to finally create my maven package from this?
I'm a bit unsure the best way to allow my build server to up issue the versions and then use those updated versions of the packages in the build.
It seems like I may have the wrong end of the stick here. Any pointers greatly appreciated.
If you had already at Maven 3.2 or better Maven 3.3+ you could have done that in a more convenient way, but if you are at Maven 3.1. you need to go
via build-helper-maven-plugin and versions-maven-plugin you can do simply via:
mvn build-helper:parse-version versions:set \
-DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}\${parsedVersion.nextIncrementalVersion} \
versions:commit
But as far as I know the versions:commit will probably not work based on support of TFS for Maven SCM....(I never tested it with TFS). But the commit step be done by something different.
I am using Jenkins as CI environment and I want to have the ability to deploy the build artifacts directly to a JBoss AS 7.1.1 server. For releasing the Maven artifacts I am using the Jenkins M2 Release Plugin.
The project structure of the project which makes problems looks as follows:
artifact-parent-pom
webapp-module
theme-module
The maven goal jboss-as:deploy can only be called on webapp-module.
To deploy the webapp-module to the JBoss server on every build, I added a post-build step calling
mvn jboss-as:deploy
on the sub-module. This works perfectly for standard SNAPSHOT builds, but not for release builds.
When using the Jenkins M2 Release Plugin to release a new artifact version, the version number is already updated to the next SNAPSHOT-version when the post-build step is executed. I tried to deploy the release version directly at the release step, but this doesn't work, hence the goal jboss-as:deploy cannot be called on the parent-pom.
All Jeknins plugins i have found only support older versions of JBoss like
Deploy to container Plugin
JBoss Management Plugin
Is there an easy way to get this working?
I have found a workaround. I made two configurations, one for the SNAPSHOTS and one for the RELEASE builds. At the RELEASE build I added two post-steps both calling the goal version:set on the parent-pom but with different properties. This results in the following post-steps:
mvn newVersion=${MVN_RELEASE_VERSION}
mvn jboss-as:deploy
mvn newVersion=${MVN_DEV_VERSION}
I´m working with Maven 3, eclipse Helios and Jenkins e Artifactory. During the execution of release plugin one of the steps that this plugin is doing, is publish in artifactory the generated release. In my organization, we have the following issue:
Only the manage of configuration can run the release through Jenkins with release-plugin, but any developer can run the release plugin through console and this execution will overwrite the release published in artifactory.
I´m looking around artifactory configurations and all developer users are with read permissions but they can update release local in artifactory.
There are any solution to block or disable the execution of local release from eclipse through Jenkins?
Thanks if anyone can help me!
I would suggets using Artifactory's release management for Jenkins, which is part of the Jenkins Artifactory plugin.
This will allow you to run release management purely from Jenkins, possibly with a dedicated user, and also run staging and promotion on releases.
Releasing/staging would typically be done to a dedicated repo in Artifactory which only the Jenkins release user has write permissions for.
The release management functionality in the Jenkins Artifactory plugin is a complete replacement for the maven release plugin (and for the Jenkins m2release plugin which is based on the latter), that is:
Faster and involves less (unnecessary) rebuild cycles
Integrates your existing Maven and SCM Jenkins configs
More flexible in how versions can be applied
Offers robust rollbacks
Also works for non-Maven build types
Move release plugin to profile (it should not be activate by default). Activate profile only when you run build on jenkins. (for profile name jenkins use mvn <goals> -Pjenkins)
http://wiki.jfrog.org/confluence/display/RTF/Managing+Permissions
I'm trying to setup a complete CI server, but I struggle on some points.
Currently, my system work as follow :
I commit local changes on my local GIT repository, then push to the GIT repository on the CI server
I then have a jenkins job triggered by the SCM change, who run a clean install and by doing so executes all my Junit and Jstestdriver test (via a local jstd server). This job deploy the snapshot artifact to a repository on my nexus repository
I installed M2-release-plugin for jenkins, and setup my pom.xml accordingly using maven-release-plugin. When i click on "Perform maven release" in jenkins job page, jenkins run mvn release:prepare release:perform, thus creating a tag in my git repo (say v000001) and deploying a versionned artifact on my nexus repository.
I don't really know if this process is fine, but i guess so...
My problem is that I want to deliver the versionned artifact in my nexus repo (say "artifact-v0000001.war") in my production tomcat. But I can't figure out how to do it.
When I do "mvn release:prepare release:perform tomcat:deploy" it deploys the new SNAPSHOT artifact built ... I don't want to do this, I want to reuse the artifact from the nexus repository.
Is there a way to doing this using a tool (maven/jenkins plugin, or external)?
Basically, I want to fetch the last release artifact on the repository, and send it to the tomcat manager for dereploying the webapp.
Do I need to setup a delivery job separated from the release job?
Jenkins, especially when combined with a tool like ANT, can do just about anything. It has a lot of plug-ins, and you can always write a script and incorporate it into a Jenkins build. Currently, I use Jenkins to deploy web applications to Windows IIS servers. What you could do here is have a Jenkins build that has your SVN path set in the source control section so that it fetches the latest version when you trigger the build. From there it should be fairly trivial to write an ANT script that copies it over the existing JAR in Tomcat, which will automatically restart it.
Your problem is that you are probably using the Jenkins release plugin, not the "m2 release plugin". The problem with the standard plugin is that it performs the regular build, saves the artifacts, then performs the release. It will then try to deploy the wrong artifacts that it created from the regular build.
The m2 release plugin solves this particular problem. There are some tricky workaround for this problem, but that's how it stands at the moment until this feature is implemented: https://issues.jenkins-ci.org/browse/JENKINS-11120 (log in and vote for it!)