Closed fgm closed 6 years ago
At the moment we don't pass payload data to Jenkins, but probably this is something which can build in easily. Still if i pass the data to Jenkins, how are you going to use them in your job? The plugin at the moment is designed to startup a preconfigured job. I agree that even if you push any branch the plugin will always run, but this can be fixed. Can you also explain what you mean with GIT_COMMIT
and GIT_BRANCH
? If you mean the environment variables of the git plugin, then this is not something this plugin populates.
Wondering: if you did not feel the need to include that feature, how do you use the plugin to trigger the appropriate builds in Jenkins ? I thought the git plugin would poll git and find the latest commit not yet tested, but this does not appear to be the case: the SHA1 returned is not the most recent, nor even on the most recently modified branch.
It's a webhook so it doesn't poll your repo for changes. Your repo should post to this webhook the job it wants to execute and than that job will run. This webhook is not different than all the other webhooks in the Jenkins plugin repo.
I'd like to use this plugin in this way, and I think it is the same way than @FGM
commit hash
so :
commit hash
So I have only one job that can run with multiple branches.
Ok this is clear and also doable. I will create a new option in the plugin which takes the data from the payload because otherwise it will break for the way other users work at the moment.
@fabienjuif thanks, you explained it better than I did, this is exactly the idea. Using git flow, we create multiple branches per day so it wouldn't make sense to have one job per branch: this only works for long-lived branches, not feature/hotfix branches like these.
Nice @sanderv32 :+1: thank you.
This is the functionality we need also. Question though, how would Jenkins show the results of multiple branch build for a single job?
@KangoV The webhook will in this case just modify your job and will check out the last SHA1, so the results will be in the same job.
@KangoV In my case this job would be mostly useful to notify the dev authoring the commit after running the (long-running) test suite. I would have normal fixed-branch jobs for long-lasting branches like develop/master.
At the moment the development branch exposes the "ref" and "after" key from the JSON payload. So now it's possible to use GOGS_REF and GOGS_AFTER as environment variables which you can use in your "Branch to build". If someone can test it i would be very happy :-)
You can download the latest snapshot from: https://jenkins.ci.cloudbees.com/job/plugins/job/gogs-webhook-plugin/6/org.jenkins-ci.plugins$gogs-webhook/
This branch needs to be tested before i'm going to make a pull request and merge it. Can someone have a look if this works?
I have a problem with a multibranch pipeline. For example, the name of the multibranch pipeline is "test" and in this pipeline i have the branches "master" and "develop". If i set the web hook url to "https://*jenkins-server*/gogs-webhook/?job=test", then he can't find the pipeline on jenkins. When i rename the job on the url to "test/master" or "test/develop", then is the hook successfull.
To fix it, you can read the "ref" property of the post data and merge the defined job name with the cotained branch.
@xXpc-freakXx I added PR https://github.com/jenkinsci/gogs-webhook-plugin/pull/20 for adding this functionality.
@sanderv32 could you merge master into development? Maybe I will be able to test it but not without the current features
You can download the latest snapshot from: https://jenkins.ci.cloudbees.com/job/plugins/job/gogs-webhook-plugin/29/org.jenkins-ci.plugins$gogs-webhook/
@tkisme Can you share the code with us? @willemvd Tried to master into development, but the development is way behind and it's not that easy to implement that code again.
https://github.com/jenkinsci/gogs-webhook-plugin/pull/20/files do you mean this?
@sanderv32 When will my pr get merged ?
@S3NS4Ti0N I want to merge it but as we don't have unit tests at the moment we have to be sure that it won't break the plugin.
Uhm ... Then what about testing it ?
I have it working like this without any problems.
@S3NS4Ti0N please write unit tests
@S3NS4Ti0N because this can potentially break even the basics of the plugin, i will merge this if more people will test you PR. If it works fine i will merge it, and for the next release unit tests should be written.
Sorry for the delay, but finally did the PR and waiting for the rebase of the unit test. After that we can release version 1.0.12
Any news ?
any progress on this to get multibranch projects working?
Could you please add https://github.com/jenkinsci/gogs-webhook-plugin/commit/316e62263d1d76cdbe58a807d88970acd5ba24c3 to master, since the build number 6 with this feature is unavailable now (rotated?).
Will it be released soon? I also need the multibranch pipeline feature. Thanks!
@maxep, for Pipeline / Multibranch Pipeline project I use a Webhook with a Payload URL like this:
https://jenkinsserver.com/git/notifyCommit?url=https://gogsserver.com/org/project.git
This will NOT trigger a build on a specific project, but will tell all project using the repository to Scan for changes. If changes are found, then it will trigger the build.
In the When should this webhook be triggered section I choose Let me choose what I need with these:
Pull Request will not work :(
More information here: https://wiki.jenkins.io/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository
I hope this can help you.
Have released version 1.0.11. Changelog on the wiki page is not yet updated (although I can see it). Because of lack of time it's not 100% tested.
Still no support for payload via environment :( Wondering what stops from merging env support? I could test it if I had the build.
If you refer to the development branch, then that's correct that the environment variables aren't there at the moment. Maybe in the weekend I have some time to merge it in the current master but I can't make a promise.
@urusha Development branch is up to date with all the changes in the master. Pipeline is not green at the moment but you can already download the development hpi here.
Thanks for your work! Tried that one, got {"result":"ERROR","message":"Job 'jobname' is not defined in Jenkins"}
when triggering (with and without new GOGs checkbox in 'Build Triggers' section). So, can not tell if ENV works.
v1.0.11 seems to work for me 👍 !
Works for me too ! :)
Works with multibranch pipeline? I still got the same error as @urusha
{"result":"ERROR","message":"Job '...' is not defined in Jenkins"}
I just had to click on Scan Multibranch Pipeline Log in Jenkins for it to create the job associated with the branch and when webhook POST
to http://jenkins/gogs-webhook/?job=MyJob
, it runs the pushed branch.
My bad, I was testing with master but my pipeline is not merged yet :) thanks @YuukanOO
@sanderv32 today we started using the GOGS_REF variable with the development branch hpi and that is working great!
@willemvd Thanks for the feedback! Will create a release from the development branch.
Development branch is merged into master and released version 1.0.12.
@sanderv32 Environment seems to work fine, but even with the last release I still get {"result":"ERROR","message":"Job 'dirname/jobname' is not defined in Jenkins"}
if the job is placed in a folder. Without folder all is ok. Should I file new report?
@urusha If this didn't work in the past, version 1.0.12 will not fix this then please create a new issue for that so that we can create a version for that one.
@sanderv32 This worked before 1.0.12. But doesn't work with 1.0.12
@urusha Will create a new issue for this.
I have set up the plugin on Jenkins and created the webhook. My jobs are triggered normally, but the only information I have access to appears to be the following:
Even looking at the plugin source code, I can't see where it would pass the payload to Jenkins. How then are jobs supposed to obtain the information they need, like - at least - the branch name on which the push occurred ? Or what am I missing ?
When I push to some branch, events are correctly sent to Jenkins, but besides the headers above, the Git pluging always returns the same
GIT_COMMIT
andGIT_BRANCH
values, which are not the ones included in the latest push, but always a constant other set of values.