When uploading artifacts to JFrog artifactory, one might set the retention to e.g. a maximum number of days. On can also set the boolean deleteBuildArtifacts: true. If not setting the latter, what will happen after the retention time has passed? Will the garbage cleaning take care of the artifacts next time it runs?
def server = Artifactory.server(...)
def buildInfo = Artifactory.newBuildInfo()
buildInfo.retention maxDays: 10
server.upload(..., buildInfo)
server.publishBuildInfo(buildInfo)
I have read the scripted pipeline syntax documentation about the Triggering Build Retention, but could not find the answer.
The reason I'm asking, apart from being curious, is because the user uploading the artifacts does not / should not have DELETE/OVERWRITE permission (there can however be other service users having it).
If deleteBuildArtifacts set to false, the artifacts should not be deleted when the retention time passes.
Instead, only the Build Info will be deleted.
For more information:
Control Build Retention
Artifactory Cleanup Best Practices - see good explanation under "Deleting Unused Artifacts"
What is Build-Info? - information about the Build Info concept
Related
I'm using jenkins pipelines, and have this disableConcurrentBuilds set - which right now if someone pushes a commit to a branch or pull request that is building, jenkins will cancel the existing build and start on the latest commit.
This is great for branches and pull requests, but I don't want this to happen to master
How do I alter disableConcurrentBuilds s.t. that it doesn't apply to master?
pipeline {
agent any
options {
disableConcurrentBuilds(abortPrevious: true)
}
As an aside - where't the documentation for disableConcurrentBuilds - I see it here: https://www.jenkins.io/doc/book/pipeline/syntax/, but it doesn't tell me what options are available. Nothing about abortPrevious on that page.
AFAIK you can´t do this, unless you have two jenkins jobs (one with disableConcurrentBuilds and another without it).
Looking at the source code seems that abortPrevious is the only option available.
Hoping to gather insight from professionals. My end goal is to trigger a jenkins build whenever a bitbucket pull request happens. If anyone could give me an ELI5(explain like I am 5) answer it would be greatly appreciated. Sorry if this is the wrong format, I am new to jenkins and stackoverflow.
What I have done so far:
Created webhook in bitbucket and gave the url to my jenkins job. example: http://jenkinsURL:8080/job/boulevard-dev/generic-webhook-trigger/invoke?token=myPull_Request_Token
Pull request webhook trigger
In Jenkins, under source code management I have: Source Code Management Settings. This is currently fetching a ton of branches, failing, then building the master branch when the job starts?
For build triggers, other stackoverflow articles have pointed me to the "Generic Webhook Trigger". https://github.com/jenkinsci/generic-webhook-trigger-plugin
I am not entirely sure how this generic webhook trigger should effectively be setup? Hoping someone has experience using it and could explain what is needed.
This is what have seen referenced in other articles.Build Triggers settings Build triggers settings 2
Questions:
What does a correct setup / example of the generic webhook trigger look like?
Currently, my job triggers when a change is made to master or merged to master, how can I specify to my job that I want the bitbucket pull request branch to be built?
Also, I found this, not sure if its related to my issue or not? https://jira.atlassian.com/browse/BCLOUD-5814
As per your requirement, you can trigger a Jenkins build whenever a bitbucket pull request happens by following the below steps, in my case, it's working fine.
Step(1) - Configure Jenkins
(i) Add your bitBucket repo and branch to source code management
(ii) On build Triggers setup Poll SCM to * * * * * for run every minute to check pull request from bitBucket.
Step(2) - configure Bit Bucket Hook
(i) Go to settings and add a new hook, now setup pull request trigger as per your requirement.
Step(3) - Make a pull request and see the new job automatically triggered on Jenkins.
My jenkins jobs use testlink to store their test results. The testlink plugin changes the build status to unstable if a test has failed.
However I want the build result to be determind by Xunit plugin in a post-build action because with Xunit you can adapt a failure threshold.
The build should only be unstable if there are new errors.
I was hoping to do the following:
--test--
--testlink -> marked as unstable --
-- groovy scipt --> marked as succes --
build.result = hudson.model.Result.SUCCESS
-- xunit, checks threshold for unstable/succes --
However it seems impossible to change the build status back to success.
So now testlink marks as unstable, and xunit mirros that status.
Is there a way to work around this problem?
Unfortunately, I don't think Jenkins will allow you to do that without an ugly hack.
For example, you can see a comment that clearly states that a result can only get worse in the Jenkins source code
e.g.
462 // result can only get worse
463 if (result==null || r.isWorseThan(result)) {
That being said....
Once the job is done, you can "technically" log on to the master and do whatever you want to already completed builds via changing the build.xmls directly.
For example, you could add a post build job that will go through the files on Jenkins master and do a mass update to replace "<result>UNSTABLE</result>" to "<result>SUCCESS</result>" to turn all builds to success. Once the job is done, forcefully restart the Jenkins server or reload its configuration for the changes to take effect.
I don't recommend this as who knows what will happen to Jenkins if you start going crazy like this. ;)
I've setup an Octopus organization with multiple repositories inside.
One of those repositories has automated tests. I'm trying to setup the Jenkinsfile in that repo to make the job trigger periodically instead of only on SCM change.
I haven't found documentation that shows this is possible. Even the job, after is automatically created shows the BUILD TRIGGER option but of course it can't be saved.
Jenkins Organization Job Configuration Screenshot
I found the way of doing this by using the "properties" option. In this example, the job will trigger by changes pushed to GitHub and also on a periodic basis (every 60 minutes):
properties([pipelineTriggers([cron('H/60 * * * *'), [$class: 'GitHubPushTrigger']])])
I am running tfs 2015 and have it build when a pull request is create to a certain branch.
It appears that the retention policies are not working on it as they should be only lasting 1 day and they are there for months at a time.
I think the problem is the source branch. on the pull requests builds it has it as the refs/pull/688/merge. The retention policies look for refs/heads/*.
Is this why they are not getting deleted and if so how can I add the pull request builds to get them deleted?
I have tried typing refs/pull/* in the retention but it comes back as refs/head/refs/pull/*
This is due to the refs/pull/688/merge branch was created and only for the build of pull request. However, the normal branch is refer/heads/(master/feature/...). It's not in the branch filters of normal branch. So the build retention has no effect on the pull request build.
For now, you may have to delete the pull request builds manually. You can also add a user voice in this site for this feature request. PM will kindly review it.
It's explained in Microsoft's documentation here. Your Minimum to keep is not zero, so there will always be something kept for the pull requests "branches".
In your case you want to add a new retention policy with 1 for Days to keep 0 for Minimum to keep and refs/pull/* for Branch specification / Branch filters
In 2017 (local, not VSTS) typing /ref/pull/* doesn't work, you end up with +refs/heads//ref/pull/* - the + being the include. Typing refs/pull/* works fine and you get +refs/pull/*