I configured Travis-CI artifacts uploading by following https://docs.travis-ci.com/user/uploading-artifacts/, it works fine for regular build triggered by push/merge, but is not triggered for the Pull Requests build. I have set "addons.artifacts.debug" to true", for the regular push builds, I can see all the debugging informations, such as
1495 Uploading Artifacts (BETA)
1496 artifacts revision=e2af40fea0aa0229ff1f26e932e018c71e95bb91
1498 artifacts upload
1499 DEBUG: setting log level to debug
However, for the PR triggered builds, I do not see any information related to addon.
Any idea how to upload artifacts for PR triggered builds?
Thanks!
Related
Background
I have a Jenkins job that does the resigning of android and ios apps based on the files uploaded to the Nexus repository.
I have 3 app versions for each android and ios.
Using nexus repo level webhook triggering concept + Jenkins generic Webhooks concept, we have achieved automated triggering of the builds when an app file is pushed to the nexus repository.
Problem
When all the 3 files are pushed in one go for any of the android or ios apps, can see only 2 Jenkins jobs webhook triggers only. one hook trigger is missing. Currently, we are seeing this issue very consistently.
The only observation that I have identified is, that whenever 3 files are pushed in one go, In the Jenkins job you see the webhook entry. see below screenshot of Jenkins job
I tried looking at multiple places but could not find a solution.
Any help here is appreciated...
Is there any possibility that we can count the number of webhooks received by the Jenkins job via code which we can see in the screenshot attached?
I have found similar issue reports in github.com: #64 #116 #126 #162 #171.
After going through all these solutions, The solution which worked for me is:
Uncheck the option "Disable Concurrent Builds" in Jenkins Job Configuration
Parameterize the job
Check options "Override Quiet Period" in Jenkins Job Configuration, under generic webhook configuration.
you can pass the quiet period from the trigger point as mentioned in the above image.
We have a jenkins build pipeline for CI/CD. The build is successful and also when the build is deployed in UAT, it shows successfully completed. However the changes are not reflected in UAT once the application is up. Don't see any errors in the logs.
Also the correct build and instance is being used.
Any idea what could be the issue.
regards,
R
I just set up Travis CI and I noticed that every time I push a branch to the remote repo, it kicks off a build. From my reading of the docs, this is not expected behavior...it should instead only kick off builds when a pull request is opened and on subsequent pushes to that branch.
Also, when I do open a pull request, it kicks off two builds, as shown in the
image.
What I want is the following:
push remote branch (Travis CI does nothing)
create PR (Travis CI kicks off 1 build)
push commit to the branch (Travis CI kicks off 1 build).
Does anyone know what additional configuration is required to achieve this result? Many Thanks.
The expected workflow can be achieved by disabling the "Build Pushes" feature as described here: https://blog.travis-ci.com/2014-03-05-repository-settings/
I have created some build configurations with snapshot and artifact dependencies (to create a build chain). The configurations are executed always on the same agent so upload of artifacts to master is not necessary.
Is that possible in TeamCity? Can I somehow avoid the upload of artifacts to master and rather pass the artifacts directly to the next build configuration in the chain?
Thanks in advance.
Martin
There is no way to disable the upload of artifacts to TeamCity, as build agents are allowed to come and go.
But since v. 8.1, TeamCity build agent caches artifacts while uploading them, so they are not re-downloaded again, when next build starts.
Is there any way in jenkins where as soon as we detect the failed build, job revert back the perforce code to the last successful build changelist and fire a build again.
Flow -
1. so as soon as we have failed build - Notifcation will be sent out to dev team with possible checkins which causing the build failure
Revert back the recent code to the last working code and submit it
Initiate a build.
It is possible, but I don't see any reasons or use case to do it as it is not a correct workflow and can be confusing.
But if you decided to do it, the next steps are required:
Example how to do it using Perforce source control.
Steps inside job settings:
Before build triggers you need to save latest changelist number $P4_CHANGELIST - 1
Perforce plugin for Jenkins: Perforce plugin for Jenkins
Build
Get last error code
Get last error code from the: batch
If code != 0 then checkout and build changelsit $P4_CHANGELIST - 1
Jenkins is not a production server. It runs tasks and do not have options that I know for that purpose.
What is your source code ? webapps ? others ?
What steps are you performing ?
Are you performing some automatic tests ?
My assumption is that you got some tests that may invalidate the build.
These tests should be runned :
* on a mock server to prevent deploying on your server
* or somewhere else
Like that, if build failed, nothing is deployed.
If build success, you can deploy your project normally.
If this not reply to your answer, please provide requested information to undestrand a bit more your job process.
If your using an artifact repository like Nexus or Artifactory to manage your project artifacts then you could always redeploy the previous working version of your application when a failure is detected.
Your not cancelling any checked in code that potentially broke the build but you are preserving your test environment. You can configure Jenkins to notify the user who checked in the latest erroneous change set and they can work on resolving the issue.
Jenkins also provides a rich API which allows you to delete a job, start a job, get information about previously run jobs. You could leverage some of these services along with your artifact repo to achieve the experience you described.