CI system: Jenkins with Jenkins Artifactory plugins, using Pipeline jobs
Language: Java, built with Maven
We have a setup where "release-versions" are supposed to be uploaded to a staging repository, and should be able to be overwritten from consecutive Jenkins builds (for example because of bugfixes in a release/x.x.x branch).
Release versions should not be allowed to be uploaded directly into a release repository, but should be allowed to be promoted into them. They should of course not be allowed to be overwritten from neither a promotion or a direct upload.
In our current setup we have successfully allowed redeploys to staging, and disallowed "re-promotions" to releases. But release artifacts can still be redeployed into a release repository.
Effective permissions for the Jenkins user:
Release repository
Delete/Overwrite: false
Deploy/Cache: true
Annotate: true
Read: true
Staging
Delete/Overwrite: true
Deploy/Cache: true
Annotate: true
Read: true
So, is there a way to:
Disallow deploys (and re-deploys) to the release repository
Allow one promotion per version to the release repository
Disallow "re-promotions" to the release repository
Allow deploys (and re-deploys) to the staging repository
Preferably only using the Artifactory permission settings.
It seems that you are on the right track. As you mentioned, you can "block" the re-deploy (overwrite) by revoking the "delete / overwrite" permissions. for a specific user, or for all of the users in your case. To answer your specific use-case what you will need to do is:
Disallow deploys (and re-deploys) to the release repository
[A1]Create a user for promotion, which will have deploy permissions to the release repository. Other than this user no other user should have deploy permissions to that repository. It should also have read permissions on the staging repository. Please note that Admin users will still have all of the permissions to all of the repositories, but I believe that this should not have any issue.
Allow one promotion per version to the release repository
[A2] Do not give the promotion user (see A1) delete permissions on the release repository. So in a case of an overwrite is being attempted you will receive an error message:
"message" : "Not enough permissions to overwrite artifact 'repoX:path/to/file' (user 'YYY' needs DELETE permission)."
Disallow "re-promotions" to the release repository
[A3] See A2
Allow deploys (and re-deploys) to the staging repository
[A4] Give the Jenkins user delete permissions on the staging repository.
That should do the trick using the Artifactory permission targets.
Related
My team uses TFS for source control. I recently created a build and a release that we use to push changes to the website to other environments. All work is done in cloud and then released to DEV so that the analysts can verify it works as needed before moving on to UAT and PROD.
If the other programmer and I both check-in files to DEV for the analysts to take a look at BUT one is approved and the other changes are not is there a way to release only the changes that get approved?
You could just use approvals to achieve your requirement in TFS/Azure DevOps Server.
When a release is created from a release pipeline that defines
approvals, the deployment stops at each point where approval is
required until the specified approver grants approval or rejects the
release (or re-assigns the approval to another user). You can enable
manual deployment approvals for each stage in a release pipeline.
For example, a manual approval check on an environment would
ensure that deployment to that environment only happens after the
designated user(s) has reviewed the changes being deployed.
In your case, if you have set up a complete CI-CD pipeline in TFS. Other programmer and you both check-in files to DEV.
First use pull request which let your team review code and give feedback on changes before merging it into the dev branch. This is the first step to verify some code changes are qualified.
Then use a build pipeline to build your source project, you could set up a CI build. It will generate a build for each commit. The build will generate some build artifacts.
Use a release pipeline with some approver to deploy your generated build artifacts to your test environment, product environment. If some stage get rejected, the deploy will fail and no changes released on that environment.
Even though other programmer and you both check-in files to DEV branch, it will trigger different build and different release.
Finally, you could also set up some approval notifications, an email message can be sent to the approver(s) defined for each approval step.
More details please refer our official doc here.
My understanding of Jenkins is that, if you have a repo (say a Git repo) that is tied to a Jenkins build, a check-in will trigger a complete repo re-build. But if you have a number of applications as part of your repo, is there a way to limit which applications will rebuild in response to a check-in? If you make a change to one application, is there a way to set up your Jenkins build process to that that check-in triggers a rebuild of that application alone?
I'm sorry but your understanding is wrong... Jenkins and Git talk to each other using hooks and if these hooks are connected to your build, only then will they build the application/branch in your repo... So unless you have specified that everything must be built, then all the application will be built, otherwise the one you checked in ...will trigger only that build
If you want, you can create a new job and add the GIT SCM hook(during configuration) and do a check in, it will build only your project and any other project that is using the same hook- key point to note here :)
So if all your applications are building then you have a configuration issue
Hope this helps :)
We have a "blessed" repository, and every team forks this repository with auto-sync enabled (blessed -> fork). In their own forked repo, the team creates their feature branches. Then they make a pull request towards the main branch on the blessed repository.
Because of the auto-sync, they cannot change the pipeline configuration in their own repo.
We would like Jenkins to limit the pull request discovery to pull requests originating from only one fork of one team.
How can we do this.
Forks are effectively separate repositories - they have different paths, different ownership, and different permissions, even though they have some shared code history.
If you're having Bitbucket send webhooks to Jenkins to trigger builds, then remove that configuration for any fork that should not have it. If you're having Jenkins poll for updates, then update Jenkins so that it only polls on the fork(s) that should build through Jenkins. And if you're moving to Pipelines, then the Pipelines YAML is distinct for each fork.
I have configure my Jenkins profile with BitBucket (Mercurial). Please see the configuration.
On Jenkins profile, changes displays correctly as per bitbucket check-in history.
Jenkins build confirms the success on new builds.
But, on Jenkins server work-space folder I don't see all changes that are supposed to be part of those check-ins
Wondering why is it sometimes missing to pull some changes part of check-in history.
You actually need to configure Bitbucket hook service (Project Settings).
This way, Bitbucket will notify your Jenkins server each repository changes on the targeted branch.
I have a maven job in jenkins. Normally at the end of the build the artifacts will be deployed to artifactory via jenkins post build action.
But if I make a release build I get an error from jenkins in this case.
So, is there a possiblity to avoid deploying the artifacts at the end of a release build.
Let me precise the error. The maven goals are 'clean install'. I need the post action for deploying to artifactory by a 'normal' job. If I make a release of this artifact via the M2 Release Plugin the deploying of the relased artifacts will be done by the M2 Release Plugin itself. But at the end of the job the post action tries to deploy artifact with the old SNAPSHOT version which is not allowed by artifactory.
Jenkins M2 release plugin (used maven-release-plugin of Maven). If you have created a Maven job (instead of a Free Style), then in M2 Release section in job's configuration, you'll see the goals are:
-Dresume=false release:prepare release:perform
If you replace it with the following M2 release plugin won't call deploy goal which is initiated by release:perform goal by default.
-Dresume=false release:prepare release:perform -Darguments="-Dmaven.deploy.skip=true"
In my case, I didn't want the artifacts to go to Artifactory as soon as release:perform and release:prepare goals were completed, so the above helped. But, even though Jenkins job has a Post Build action as "Deploy to Artifactory" to either snapshot or release repositories (depending upon what kind of build you have aka automated/manually run build job OR by running Perform Maven Release ), it never called the post build action.
This can be good in the sense, now I can call deployment using the generated release artifacts in an environment and if the deployment/some IT tests are successful, then I can upload the artifacts to Artifactory. Downside is, what if your deployment depends upon fetching the new artifact from Artifactory/Nexus (i.e. somewhere in deploy script's logic) then you can't have that working until you copy artifacts from one job to another child job.
Apart from that, maven deploy goal requires valid / settings in either settings.xml or pom.xml where the you specify for each of the above sections, which are defined under section, must match with the value of section defined in setting.xml/pom.xml.
One can defined / set the value of section to use a non-release repository which is higher in order (for artifact resolution) than a snapshot repository i.e. use libs-alpha-local or libs-stage-local and then let maven deploy goal deploy the artifacts to Artifactory/Nexus.
Later, upon successful deployments to higher environments (like QA/PRE etc), you can move the artifact from alpha/stage to libs-release-local.
IS_M2RELEASEBUILD Boolean variable which comes with M2 Release plugin can be used in a conditional step to deploy here or there or not at all.
In the configuration of the 'Maven release build' you can set in the advanced mode a 'Release environment variable' (default is IS_M2RELEASEBUILD). Later in the post-bild-action 'publish artifacts' you can check if this environment variable is set and then the deploying is skipped.
I'm thinking you may want to create a separate jenkins job just for your release builds. And under post build action to run different set of maven commands just to package the artificat and not install it to the artifactory. That being said if other applications depends on that artifact you do not want to release. This may be causing versioning problems.
You should take a look at Artifactory Jenkins plugin. 1. It deploys with errors. 2. It has built in release functionality. 3. It will provide you with unique buildInfo functionality for saving build information tougher with artifacts in Artifactory, https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
If I can assume you're using the M2 Release Plugin, then there's another issue.
Skipping the deployment after a release would be an unnecessary workaround, since I've seen this work. You should try to fix this by the root cause.
It would help if you could provide more info about the error.