I have DVCS account in place. How do I make it update periodically without clicking being?
All the time commits from Github are appearing by JIRA issues after i manually click Synchronize in DVCS accounts administration.
How can I make it happen automatically?
Answer from support was to make a Webhook from the Github side. Automatic polling from JIRA side is done once per hour and this interval can't be changed since JIRA 6.3. Anyway there is JIRA DVCS Connector issue to vote it back into the JIRA -- https://jira.atlassian.com/browse/DCON-379.
Also I was provided with KB article which describes why and how to do it -- https://confluence.atlassian.com/display/JIRAKB/Slow+Appearing+Commits+from+BitBucket+or+GitHub+in+JIRA
Related
I have a Github repo which hasn't been updated for a long while (up until today).
I would like to notify users who cloned it in the past that the repo has been updated and that they better pull the changes.
Is there a way to do that?
You can use GitHub webhooks for this. You'll have to read the docs and add your own consumption logic for it.
If you rather not build your own consumption pipeline, consider using LightFlare (I'm the creator) that has out of the box support of consuming Webhooks events from many services (github included) and notifies you at your choice(s) of destinations (slack / email etc ...).
Research I've done before raising this question:
[github] single user pr - no relevant results
[github] single user pull request - no relevant results
[github] approve own pull request
github protected branch require pull request (Unanswered)
A potentially relevant question, but around a multiple user environment, so there were workarounds. I don't have a workaround.
'[github] approve own pr` - no relevant results.
Quite a few Google searches
So my problem is simple: I have a personal GitHub repository that I am using to manage my website code. I would like to prevent accidental check-ins to the master branch because I do not want the CI/CD pipeline that I'm building to trigger unless a feature is complete; I'm planning to use issue-linked feature branches to handle updates.
My problem is that I cannot seem to set this up without having someone else to approve the pull requests, which I don't have. So the question is: How, other than creating a secondary git account to handle PR's, can I protect a branch to prevent accidental check-ins from happening, without having someone else on my team to approve those pull requests?
I know that I can do this in Azure Repositories, however, I quite like the GitHub environment so I'd rather do this in GitHub.
I managed to work around this. At the time I made this request, I didn't have automated tests set up (Something I believe all projects should have for completeness). When I set up validation requirements to merge into Master, I could not directly check-in to Master because those checks had not been run.
I could still approve the PR myself, so that was allowable, however, I also had to ensure that all pipeline checks had completed before that PR could complete.
It's not a complete answer because if you are not running a CI/CD pipeline with test running you will not be able to take advantage - but it's easy enough to set something dummy up that will always pass to enable this solution. Until GitHub.com provides a self-approval allowance, it seems to be the best answer.
I'm always happy to hear alternatives though!
On Github, I've noticed that some pull requests say that they're "Good to merge" because they have passed a Travis build passed. I have used Travis a little bit, how does it integrate with pull requests on Github?
Here's a screenshot of what I'm talking about:
Once you've set up Travis and tell it which branch need to be tested, it'll automatically run a build on each pull request targetting one of those branches (and every commit pushed to these branches).
Note that the Travis notification on Github only appears after the build/test is over (roughly 15min).
Also, this isn't Travis specific. Github has an API for continous integration, works for TravisCI, also works with CircleCI.
Note that since December, 8th 2014, you can see multiple status from multiple services on your pull request.
See results from all pull request status checks
Since we introduced the Status API, you've been able to improve the quality of your code by including the status of a pull request within the conversation timeline, for every push.
Before today, you've only been able to see results from one service. Now you can see all your results at once, from multiple CI systems that test your code against different platforms to simultaneous security testing and code coverage analysis.
You can also see how the status of a pull request has changed over its history by clicking the icons listed next to individual commits.
Since July 20th 2015, that status information will be clearly visible in the PR.
See "Clearer mergability information for Pull Requests":
Each month, 119,000 repositories on GitHub use automated status checks (via the GitHub Statuses API) and it’s important that this information is presented in a way that you can easily understand.
When you’re ready to merge a pull request, you should be able to see that it is ready.
If a check isn’t passing, you should be able to see why.
I want to integrate github with a external service.
In particular I want certain actions to happen when an issue closes or a milestone is completed. I can see how to do the above for issues by adding a webhook against the issue event updates http://developer.github.com/v3/repos/hooks/.
However, I don't see any events around milestones.
Why is that? Is it an ommission? I have seen some integrations of github milestones with the google calendar - I am assuming that this requires webhooks (I wouldn't expect them to use polling against the milestone api).
One alternative I have thought if there is no such event, is to listen for issue events and every time an issue closes, check whether this issue is associated with a milestone, and if it is check whether all other issues associated with that milestone are already closed and then create my own "milestone completed" event. ( I don't need milestone create events).
Any suggestions would be greatly welcomed.
Yeah, there are no milestone events at this time. Your idea using issue events and checking the milestone closed issues count is probably the way I'd do it too. Remember to use conditional GETs when fetching the milestone info in order to reduce your API quota consumption.
There are now webhook events for milestones - introduced by Github in October 2016. See:
https://developer.github.com/changes/2016-10-27-new-label-and-milestone-webhooks/
We've decided on a version control system - using Mercurial clients and Bitbucket for repositories. But it's just occurred to me we have a problem I didn't consider.
We have an internal development LAMP server (Ubuntu) and all the developers work on websites stored on it, which means all developers share a single file source and we are all working from it. It's rare that two different developers will work on the same site at the some time, but it does happen occasionally. This means that two developers can easily overwrite each others work if they are working on the same file at the same time.
So my questions is: what is the best solution to this problem? Bearing in mind we like the convenience of a single internal server so that we can demo sites internally, and it also has a cron job running for backing up the files and databases.
I am guessing each developer would have to run their own LAMP (or WAMP) servers on their individual workstations, commit, and push to bitbucket repository. And of course whenever working on a different site, do a pull and resolve any differences as per usual. This of course takes away the convenience of other team members (non developers) being able to browse to 192.168.0.100 (the LAMP server IP address) and looking at the progress of websites, not to mention that some clients can also access the same server externally (I've set up a port forward and limited to their IP addresses) to see the progress of their websites too.
Any advice will be greatly appreciated.
Thanks in advance.
I think, you have to seriously re-think about used workflow, because LAMP-per-dev is only slightly better than editing sites in-place
I can't see place for Bitbucket in serious corporate development - in-house resources are at least more manageable
I can't see reasons don't use Staging Mercurial-server (pseudo-central) with Staging internal LAMP-server (which you have and use now)
I can imagine at least two possible choices (fast, dirty, draft idea, not ready-to-use solution), both are hook-based
Less manageable, faster for implement
Every developer have in own local repo hook, which after (each?) commit export his tip and copy exported to related site space. Workflow: commit - test results on internal site
Advantages: easy, fast to implement
Disadvantages: Can't prevent (due to distributed nature) overwriting of tested code by code from another developer
Manageable deploy, harder to implement and manage
LAMP-server become also Mercurial-server, which hosts "central" clones of all site-repos, updated by push only from developer local repo. Each repo on this server must get two hooks:
"before-push" checks, is it allowed to push now, or site "locked" by previous developer
"post-push", which export-copy received data and perform also control function for hook 1: based on conditions (subject of discussion) lock/unlock pushes to repo
Workflow: commit - push - test results - tag WC with special (moved) tag - commit tag - push unlocking changeset into repo
Advantages: manageable single-point testing
Disadvantages: possible delays due to push-workflow and blocking of pushes. The need to install, configure, support additional server. Complexity of changegroup and pretxnchangegroup hooks
Final notes and hints for solution 2: I think (not tested), special tag (with -f for movement across changesets) can be used as unlock sign (bookmark will not satisfy condition "move by hand"). I.e - developer commit (and pushes) non-tagged changeset, tag (f.e) "Passed" mark some older changeset. When testing results on Staging server is done, developer tag WC with the above tag, commit tag and pushed to central repo. changegroup hook must detect pushing of .hgtags and (in some-way) allow future data-pushes (control-pushes must be allowed always)
Yes, the better solution is probably to set each developer up with a local server. It may seem inconvenient to you because you're apparently used to sharing a server, but consider:
If you're really interested in using a single server as a demo server, it's probably better that people aren't actively working developing on it at the time. They could break stuff that way! And developers shouldn't have to worry about breaking stuff when they're developing. Developing often means experimenting.
Having each developer running their own server will give them flexibility to, say, work disconnected. You've got a decentralized version control system (mercurial), but your development process is highly centralized. Even if you don't want people to work remotely, realize that when your single server goes down now, everybody goes down.
Any time a developer commits and pushes those commits, you can automate deployment directly to your demo site. That way, you still have a quite up-to-date source on your demo server.
TL;DR: Keep the demo server, but let your devs work on their own servers.