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)
Related
I recently created an extension and I am trying to set up a workflow to automatically publish the extension to the VSCode marketplace when I see fit.
I have read the official article which only shows fractions of the final set up and which also seems a little outdated. Following that and copying from misc. repos on Github, I have patched together a semi-working solution. Yet, the workflow is really odd.
It seems like the tutorial is suggesting you try to run a vsce publish when a new tag has been pushed or a release has been created/published. But here is what that looks like:
Make a commit(s) with new code/features you want to add to the extension.
Change package.json manually to update the version number.
Tag the commit manually with the same version number.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version and to trigger eventual action)
Github action is executed and hopefully succeeds, otherwise you will have to redo a bunch of above steps.
The above workflow is not optimal as it requires you to enter the version number about 3-4 times. This can be improved somewhat.
Make a commit(s) with new code/features you want to add to the extension.
Run vsce package <version> to create a new commit with a new tag and also update package.json in one command.
Push commit and tag.
(make a release manually on Github to have consistency between tags and published extension version)
Github action executed vsce publish which almost certain to succeed since vsce package <version> already succeeded previously.
This scenario is better but still has some problems:
The Github Action will need to listen to a new tag push.
Could it also create a release automatically?
Is it common practice to always create a Github release from a tag?
Step 2 requires you to build the project to a .vsix file.
Can this be prevented?
We could instead do this on Github through and action. But what would we listen to to trigger this action? We need a version number, but it can not come from a tag since vsce package <version> creates a new tag and updated the pacakge.json for us.
What is the optimal workflow to make this process as painless as possible?
I have a project on AppVeyor that I want to build in two (or three) different scenarios:
Anytime it's on the master branch no matter which files changed, but not a pull request
If it is a pull request on the master branch when certain files have changed
(Maybe if it's on a different branch when certain files have changed)
Is there a way to configure appveyor.yml to do this? I'm aware of how to use APPVEYOR_PULL_REQUEST_NUMBER in one-liners, but I want to be able to apply it to the entire appveyor.yml, and combine it with the only_commits: options.
You can create 2 projects on AppVeyor connected to the same GitHub repo:
For the first project got to GitHub repo settings, find Webhook connected to this project and uncheck pull request
For the second project set only_commits for those certain files according to commit filtering doc
Optionally, for the first project set skip_commits for the same files according the same commit filtering doc, to eliminate duplicate builds.
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.
I want to accomplish following via teamcity in my CI box.
Master branch commit : Build and Release
Beta branch commit: Build and Release to Crashlytics
All other commits to any other branch: Build
(side note since most of our development branches may or may not contain a prefix, it makes it difficult to use "feature-*" branch naming)
Following this question Select Git branch for TeamCity Build
I have created a Configuration Parameters in my project settings
and then
my VCS root settings
Then I created a build template
When I created builds I made sure branch name is correct
I have also tried to edit Triggers
How ever this is not working because when I push a commit to Beta branch
I think because of ref/heads/* default build is running all the branches
and Beta and Master displays "Pending"
How can I correct this?
I solved the problem by talking to other developers and making sure that all development branches uses a prefix, in this case XAAI-
then in my VCS root settings
for triggers in each build configuration I make sure it only is triggered when that branch is checked in.
for example for QA (Betabuild)
this is the tricky part , for Development branches I had to give an empty parameter, I dont know why (maybe because something needs to check default branch which is supposed to be ref/heads/) but whatever the reason it is working.*
and then finally whole thing looks like this
That pending thing is still annoying but , I think at least it is working as I envisioned now.
If you want your builds to only trigger automatically when the default branch is pushed to, you can add a branch filter to the trigger like so +:<default>.
This is dependent on the assumption that you have setup the %BranchName% parameter in each build configuration correctly. IE, for your Default build, make the %BranchName% parameter = master.
As a side note, you will still see all pending changes for each branch, but the trigger will only run when you push to your default build if you add the branch filter. If you want to get rid of the pending changes for each branch, you'll need to setup your vcs root specfic for each configuration to filter out the branches all together.
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)