My goal for Jenkins is to trigger a build from a github branch automatically, build the application, make a update to the source and then push the source update to the same branch.
All is working except I find myself in a loop. I'm using the build trigger "Build when a change is pushed to GitHub".
When I push the update to the same branch from within the job, it then triggers the build again putting the whole process into a loop.
What I'm looking to do is somehow put this trigger on hold until the whole job is complete.
(I happen to be building an xcode project and updating the build version number in the plist... not sure that is directly relevant to the problem at hand)
When I push the update to the same branch from within the job, it then triggers the build again putting the whole process into a loop.
Then it would be best to push to a different branch, considering that, even if the GitHub webhook fires again, at least it will fire a JSON payload, with, for the push event, with a different branch name
ref string The full Git ref that was pushed. Example: “refs/heads/master”
By checking the name of the branch push in that payload, you will be able to avoid the loop.
I found myself in the same conondrum, and found the answer:
https://liviutudor.com/2015/12/09/jenkins-ci-trick-to-prevent-task-from-triggering-itself-on-scm-commit/#sthash.j7YTr3l0.dpbs
Basically you can choose the option "Polling ignores commits from specific users", and add your bot's username =]
Simple & elegant
Related
In a repository we have :
a workflow that runs on: pull_request
so it runs each time I open/ commit to the pull-request (which I opened)
we have an action (runs manually) that commits to the pull-request (updating some files in the branch)
when the second action finishes to run, I can see its commit on the pull request
but it doesn't trigger the first workflow to run again
(in order to run the workflow after the action's commit, I need each time to insert a dummy commit or close and re-open the pull-request)
Is there another way to trigger the first workflow after a "bot" from the 2nd github action commits?
Don't do that. GitHub generally "dislike" having workflows trigger other workflows, for the obvious reason.1 Instead, write a reusable workflow, then use and re-use it.
See also Github Actions - trigger another action after one action is completed.
1If the reason isn't obvious, see this question. Follow the link until it becomes obvious why this is a bad idea. (In Computer Science, see the definition of recursion. In Philosophy, a closely related idea is called Begging the Question.)
You could add push trigger as well to the workflow as follows:
on:
- push
- pull_request
It should then run the workflow when you push a commit or tag. See docs here.
I have a pipeline that runs every time the main branch gets updated (runs Sonarqube and creates a tag)
I need to get the differences from the previous main status and the new one. Most of our updates to the main branch comes from a merge request with the no fast forward option so normally just doing a git diff HEAD HEAD~1 should do the trick but I was wondering if there is anyway to get that previous state, for example, we perform a no fast forward merge or we manually push more than one merge
I checked the predefined variables without luck https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
Thanks!
It would be ideal to refresh github-code-scanning alerts when a branch pr is changed, removing old alerts when they become outdated and avoiding duplicating new alerts.
Following the behavior:
When a new commit is added: Run on this new commit
When a force push occurs: Re-run (deleting old alerts) on all commits which changed (or more simply, deleting all alerts and re-running on the entire branch).
Specifically I have a repository with code scanning and some generic PR (https://github.com/JonathanWoollett-Light/testing-git-hooks/pull/1) here given my force push my desired behavior would have been for it to delete the first alert or not generate the second duplicate alert.
Is this possible? Where should I begin looking to accomplish this?
I'm running builds with AzureDevops piplines. When I'm creating new pipline I'm not queueing it and just saving. If CI trigger is selected pipline will run if anything is checked in.
But on the very first run/chack-in pipline will be liked (associated) to ALL check-ins (changesets/commits) that happened before the current one and to all workitems of those chack-ins.
This behaviour is not desired for me. Is there a way to disable it?
On all subsequent check-ins build will be associated only with the one that triggered the pipline. And this is what I want for the first build as well, for it to be associated only with the chack-in that triggered it.
Without seeing exactly what's happening, it's hard to provide advice. It could also behave differently if you're using Git or TFSVC variants. Here's a few things to try:
Disable the CI trigger, do your first check-in, then re-enable the trigger. That might skip the change-set and work item affiliation one time.
Delete the offending build after it runs or do the laborious task of manually deleting all links in it.
If you're using Git, you can also limit the CI trigger by using a Pull Request with Squash merge. This will consolidate the commits down to one.
There isn't the way to disable it. It would compare previous run, then include all changesets between them. So, for first run, it must includes all previous changesets.
You may create a new branch for a folder, then configure build for that branch. Learn about branching strategies for Team Foundation Version Control (TFVC) and how to select an effective strategy
I'm pretty sure this setup was working at one point for us. I changed our builds a bit to reflect some operational changes and now the CI git branch trigger isn't working. I'm trying to get it so when a PR is merged into master it triggers the release build. I can trigger this build manually but not when submitting a PR to master from dev and then accepting the PR (on github).
Is anyone else having issues or know whats wrong?
Adding an answer so this more visible. #starain-MSFT comment was the solution.
I added a new build with the same trigger and it fixed the other one not getting triggered. Then deleted the new build I had added and everything is working.
Cloning my build definition didn't work, unfortunately, and neither did saving a trivial change to the build definition. Instead, I had to explicitly disable the CI trigger, save, then re-enable it and save it again. (Annoying, because I had to redefine all the rules.) But give it a try if the accepted answer doesn't do it for you.
I also wonder if adding a random branch to the triggering branches list, saving, then removing the random branch and saving again would work (and save you from having to redefine everything).