With our Gerrit setup, at times we need to kick off the Gerrit validation after non-Gerrit actions take place (internal jobs finish).
These internal jobs are out of our control, so we can't integrate them directly into our CI system.
We get stuck in a chicken-and-egg situation because we need the Gerrit validation to kick-off at an ad-hoc time but have no way of doing so and remain blocked from merging to master.
As a workaround, I was thinking there would be a way to push something like an empty patch-set, but simply changing the sha of HEAD and pushing doesn't seem to be working as I get:
! [remote rejected] HEAD -> refs/drafts/master (no changes made)
Another idea is to make a trivial change to the commit message but that doesn't seem like an ideal solution.
Is there a best-practice for kicking off the Gerrit validation at an ad-hoc time? Perhaps a way to push an empty patch-set?
Related
‘’’’
Need to know if there is any possible way to capture the event of pull request creation in bitbucket to write a custom script using this event.
Dont want PR to trigger any automatic build instead just need capture the pr creation event to write a custom python script to trigger certain activities through script run.
One option is to read/continuous poll the bit bucket PR creation page to identify the activity/event but it sounds to be a bad scripting standard and not a good practice.
Is there any git command to identify PR creation at feature branch and to merge into parent(say its DEV) and also git command to capture PR default reviewer names???
So that, these git commandS can be used in script To track if any PR is raised?
Verified many websites and read many articals and unfortunately no where found the possibility to capture the PR creation event in bit bucket?
Great if anyone can post the possibility to capture the event to write our own custom logic with the PR event capture
‘’’’
PR is not a part of git. It's a concept unique to code hosting sites like Bitbucket, Github, etc. Therefore, theoretically it's not possible to capture PR creation event using git tool alone.
You can poll the Bitbucket REST Apis for the PR list. The response is in Json format, stable and easy to parse, so it's not really a bad practice (as when you parse the raw html).
Another way is to set up a Bitbucket webhook that triggers on PR creation event. You then need to run a web server (something like this) to accept the webhook call and run the corresponding scripts.
I am having an issue with my Jenkins pipeline that pushes a tag as one of the steps, this ultimately kicks off the build again causing a loop.
Doesn't GitHub have a way of only sending a webhook with a source commit to the repo and not a tag?
When you register for a given type of webhook with GitHub, you get notifications for every webhook of that type. Filtering is not possible for efficiency reasons, since GitHub sends massive numbers of webhook payloads. The assumption is that your service will discard any events you don't care about.
If you don't want Jenkins to build when a tag is pushed, then configure it not to do that. From some quick Googling, it appears you can control the refs to be built, so you may want to configure it to just build refs/heads/*, which doesn't include tags.
I am working on a plugin for TFS to hook certain operations. I'm able to successfully hook code pushes via using an ISubscriber on PushNotification, but am having trouble finding any type that matches up with the completion of a Pull Request.
A little more on what I'm trying to do. I currently have a PushNotification hook that has some branch specific checks that it does. Some reject a push, others provide notifications to users using some complex rules. I need a way to be able to provide the notifications at a minimum, and ideally prevent the pull request from going through. I can't provide notifications prior to the pull request going through as the notifications should only occur for code being placed in our main repository.
Long term, I want to switch it over to using the webhooks and some async approval, but I don't have the time to adapt the tools to work like that and setup the additional server needed to make that happen. If there's no good solution, I'll simply disable pull requests for now until I can write proper services for it, but if there is a way to reuse the adapted hooks that can run on the PushNotification ISubscriber, it would be extremely helpful.
I've been reading a few articles and watching a few videos on Jenkins. I'm wondering how easy it would be once the master branch has been deployed to a staging server to automatically send an email to the client notifying them of the url to the staging server and also giving them a link to "deploy live". This way the client can see the changes, make sure they're happy with it then deploy it themselves without having to email anyone requesting it to go live.
Anyone got any idea how easy this would be to do with Jenkins? There may be a plugin that does this but so far I've not come across anything.
I saw a talk where a guy does this to notify QA of a new build to test, as well as notify when a build is ready to be published to production.
Basically the last automated job (deploy to staging job) has a post build step to send an email to some address. The body of the email contains a link back to the REST API for the "deploy to production" job, triggering a build.
Email recipient tests things, and if satisfied, clicks the link and Jenkins runs the production job. Obviously this requires that the recipient has some kind of access to (at the very least, the REST API of) the Jenkins instance. That being said, there's no reason you couldn't set up your own system to take limited external requests and forward them to your Jenkins API.
The video link (including time reference of the relevant part) is: https://youtu.be/3HI7mv_791k?t=3169
If you've been watching a few videos you might have already come across it, but it's quite long so you might not have watched it all.
Is it possible to setup TFS/Test Manager so that it sends out an email after a test fails?
Yes, it is possible but it requires quite a lot of changes/additions to the process template and possibly a custom-made activity.
After tests have run, we check if BuildDetail.BuildPhaseStatus has status failed
We send mail to everyone who has changesets committed to this build, so the build goes through BuildDetail.AssociatedChangesets (you need to have AssociateChangesetsAndWorkItems on) and get the committer username.
Unfortunately for us, there's no good correlation between TFS username and email address at our place, so we had to create a custom activity that looks that up in the AD.
The actual email is sent with the BuildReport action from Community TFS Build Extensions. We modified the xslt, but that's not really necessary. We also wanted to include a listing of the failed tests, and that required modification of the action itself (test data isn't included by default).
Looking at this description and all the work made to get this working, I'm beginning to wonder if it was worth it ;).