I can checkout the code from github using import org.ajoberstar.gradle.git.tasks.*
. But I want to check out the code immediately after code checkined to github repository automatically and deploys it into web server.Is there any plugin to identify the commit history in github repo.Or some other ways to do it.
Two options I can think of:
Use a git commit hook to trigger the gradle task.
Periodically poll git log to check for new commits (you might be able to use gradle's new continuous mode to achieve this)
Related
I use the vscode extension to modify code in a github depot but i would like to know if it is possible to execute the code without downloading it
You could add a GitHub Action in your repository, which would checkout your repository, on demand, when you trigger it manually.
That same GitHub Action ca, execute any command you want inside the checked out repository (on Azure server: no need to download the code).
The GitHub Actions for VS Code could be used to trigger that same workflow directly from your VSCode, but might imply a clone first.
I have configured a multibranch pipeline job in Jenkins linked to our GitHub repo which is working nicely, feeding back the status of checks to the pull request in our GitHub so we know if the branch is good for merging in.
What I don't see are any open pull requests listed against the Job in Jenkins:
We also have the Blue Ocean plugin in installed and no PR's are shown there either.
Anyone know why this is the case? Am I missing another plugin\config?
I had this issue as well. I tried what joey suggested, but that did not work. I found out that if you add PR-.+ (or PR-* as a wildcard) to your regex filter for branches to include, the pull requests "magically" appear. The documentation of this was found here. It's very frustrating that the "official" documentation for this plugin does not explain this (at least from what sparse documentation I could find). The configuration for my project, which works, is here:
I'm not sure if this is a recommended way to use this plugin for this use case, but Jenkins never seems to have ample documentation.
I was getting the same issue. But this time within Blue Ocean UI as shown below
The fix was to switch from using Git to GitHub Branch Source at the job level and configure GitHub Branch Source. The job type was Multibranch pipeline.
One possible cause could be that GitHub is unable to connect to Jenkins directly due to a firewall. This is likely the case if GitHub never reports the status check as completed, in other words, it hangs forever.
In this case, polling is an easy solution. Go to http://_jenkins_ip_:8080/job/_job_name_/configure and select the "Scan Repository Triggers" tab. Tick the "Periodically if not otherwise run" checkbox and select an interval. I have 15 minutes on mine.
The first time this is done, there should be an immediate scan and it should detect the pull request, otherwise, there might be something else going on. Check the "Scan Repository Log" page on the job, as it might have useful info.
By the way, I did not install the "GitHub Pull Request Builder Plugin" as the page says that it has a security issue. Instead, the "GitHub Branch Source Plugin" is being used. Some other related plugins installed:
Git client plugin
Git plugin
GitHub API Plugin
GitHub Authentication plugin
GitHub Integration Plugin
GitHub plugin
I'm also using Blue Ocean, but this is not required, it simply provides a different UI.
I know that this is an old topic, but I had the same issue while I was trying to visualize my Pull Requests from Bitbucket and I hope this answer will help other people in need. In my case, I was using Bitbucket Push and Pull Request Plugin, which is pretty similar to other GitHub Plugins for Jenkins.
My problem came from the fact that I selected Git instead of Bitbucket in Branch Sources >> Add Source section. I suspect the same thing happened in this case, where the two options Git and GitHub are even easier to confuse.
Scenario:
Job 1 should be triggered on every new commit to github repository.
Job 2 should be triggered only when adding a tag to that same github repository.
If I configure the Github Plugin to use webhooks, it seems that if I try to set 'Branches to build' to anything permissive (**/* or refs/heads/*), it will build any push to github - which includes adding and removing tags.
Additionally, I can't seem to find a way to ignore all commits, and ONLY build tags.
I'm using Jenkins 2.32.3, Git Plugin 3.1.0, and Github Plugin 1.26.1
Im going to start off by saying that this might vary depending on jenkins and plugin versions.
But in the normal git plugin, when you go to the job config you can select Additional Build Behavior. Under add you can select to ignore commits with certain messages (i.e. comments) or to ignore commits by certain commiters (i.e. the build user)
I'm using Jenkins for CI, I'm trying to establish a build strategy. My point here is to build
after every commit. I saw that I need to create post-commit file in the hooks directory of my
project repository.
The porblem is that I'm using SVN as an Eclipse plugin, so I don't really have a repository,
I'm just using "right click -> Team " on my project to synchronize/update/commit ...
I can't see where to create my post-commit file in order to launch a Jenkins build.
Does anyone kow how to deal with this issue ?
I've seen many posts before, but none of them was helpful !
Thanks
The simplest solution is to use Poll SCM in your Jenkins job and have it look for changes e.g. every 5 minutes. It won't trigger the build instantly on commit, but it will decouple your SVN and Jenkins a bit more.
How can I write a post_commit (like) plugin that is executed only when a specific branch is commited?.
Right now I have written a plugin in "~/.bazaar/plugins/" directory, but the problem is that the plugin is executing when any branch in the repository is commited.
The idea is to trigger a call to a Continuous Integration server (Hudson) to automatically build the project-job when a revision is commited
Thanks.
There is no automatic way to associate a plugin to specific branch, but you can use configuration files (either branch.conf or locations.conf) to control the behavior of your plugin. So your plugin only should open the branch config and read some option from there, for example:
my_plugin_post_commit = enabled
And if required option is present in branch config then you execute required operations, otherwise your plugin simply exits and that's all.