I have checked bot schedule for manually,periodically and poll for new commit(it works in 5 min) all are three option working properly, but I am unable to understand fourth option "On commit using custom trigger script".
Please any one can explain this how does this fourth option work? will it work for immediate integration on each commit.
Please Check below link also:
http://www.likelyanswer.com/30202671/How-Do-I-Create-A-Trigger-Script-For-Bot-On-Xcode-5-Ci%3F
ption here]1
This is based on my own investigation and may be completely wrong in future releases.
The Xcode service exposes an HTTP endpoint to perform an immediate integration when the trigger script schedule option is selected:
POST /xcs/kick-commit-bots
Parameters:
repository: URL to the repository as shown in the bot's settings.
branch: (optional) Name of the branch to trigger integrations for. If specified, only bots configured to build this branch will be integrated. If unspecified, all bots for the specified repository will be integrated.
Example:
curl http://server.local/xcs/kick-commit-bots \
-d repository=ssh://server.local/git/example.git \
-d branch=master
To make use of trigger script scheduling option you'll need to create a repository hook to trigger this endpoint on receipt of new commits. OS X Server contains an example hook in /Applications/Server.app/Contents/ServerRoot/usr/share/collabd/server/ruby/kick_build_bot.rb. For hosted Git repositories created through the Xcode service a post-receive hook using this script is created for you automatically.
Note that the repository URL sent to /xcs/kick-commit-bots must match the repository URL as shown in the bot's settings in the web interface. It seems that for hosted repositories the URL can change - sometimes an ssh: URL is used and sometimes a file: URL is used.
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I just setup CI/CD for a GitHub repo.
The CI build which validates a pull request is setup up as GitHub Action.
The CD build (which should run after the pull request was merged) is setup using Azure Pipelines as i would like to use the artifacts generated as a trigger for a Release Pipeline using Azure Pipelines as well.
The only thing that's still bugging me is, that the CD Build is also triggering automatically for a pull request and i can't figure out where i can configure those checks.
The checks currently running when a pull request is created are the following:
I want to get rid of the Continous Delivery Build here.
I tried to configure the branch protection rules but this has no effect:
On the Azure Pipeline side i completely disabled the triggers:
But this also has no visible effect to me.
I tested Disable pull request validation in the Triggers of the azure devops pipeline. On my side, it works well, and the build pipeline validation check is not displayed in the github pull request.
You can first check whether the pipeline source repo that you set the "Disable pull request validation" option corresponds to the github repo that created the pull request. Then try a few more times, it is possible that the settings are not applied immediately.
In addition, as workaround you can opt out of pull request validation entirely by specifying pr: none in yaml. Please refer to this official document.
# no PR triggers
pr: none
I created a webhook in jenkins and connected it to github webhook & services.
I came upon the following issue When the build is completed, the pom.xml is updated with the version and tag . This triggers build job again and its goes into a loop until, I manually stop it .
I have set the build trigger to "Build when a change is pushed to GitHub"
I would like to find out how to stop the build trigger when the pom.xml is updated only as part of the build?
In the source code management job configuration section add Additional Behaviors and select Polling ignores commits from certain users and provide the user name your Jenkins job uses to checkin pom.xml. You can also use Polling ignores commits in certain paths and provide path to pom.xml.
I'd suggest not committing the version update to the master branch but create a separate tag every time. Something like this:
v1 v2 v3
/ / /
--A----B----C (master)
I got this approach from Real-World Strategies for Continuous Delivery with Maven and Jenkins video (corresponding slides) - it contains other tips on setting up build pipelines with Maven as well.
My team and I were setting everything up so that Forge was in charge of deployment exclusively, while a CI cloud service would run unit/integration tests on each push to develop or master (staging or production, respectively).
Given the fact that Forge will trigger a deployment on each push to master (or any other branch), where does the CI server takes place in this model? Can I get a quick explanation of the workflow (and if possible an example CI cloud that would work with it)
Next to the auto deploy trigger Forge provides you a deploy-hook-url that can be called to trigger the deployment script. Usually the ci cloud service provides a way to customize the test/deployment process with some sort of bash scripts (curl) or gives an option to call an url after a successful run.
For example I used to use codeship for ci and they have an option in the settings called deployment where i could insert a custom script which calls the trigger url like curl -X GET https://forge.laravel.com/servers/xxx/sites/xxx/deploy/http?token=xxx
deactivate the aug-deploy trigger
customize the ci settings and call the forge-hook after successful run
Rather than having teamcity log onto the gitolite server several tens of thousands of times each day - and also sitting around waiting for the poll to happen (or starting it manually).
It would be nice if it was possible to set it up gitolite hooks that inform TeamCity that the repository has changed.
Is such a configuration possible with TeamCity and gitolite?
I know Jenkins has a github plugin that works nicely - I use that setup for some Minecraft CI I am running privately.
One way would be to gitolite (through a VREF hook) to call TeamCity through its REST API, in order to launch a build through web request.
You just need to make web request to the following URL:
http://YOURSERVER/httpAuth/action.html?add2Queue=btId
, where btId is build type Id – unique identifier for each build configuration.
To get it, you can just look for it in browser address bar, when clicking on build configuration, or use TeamCity REST API for details.
The OP Morten Nilsen didn't need a VREF:
add a file "post-receive" to .gitolite/hooks/common and
run gitolite setup --hooks-only