I'm part of several teams that depend heavily on GitHub's convenient "send an email every time anyone pushes commits" service, which is slated to disappear in a few weeks. I'm aware that it's been deprecated in favor of a more general WebHooks mechanism, but the docs are not very clear on exactly how one would instantiate the general mechanism to get back what the existing one does.
What is the easiest way to replicate the functionality that's going away?
Beside the original post (Replacing Services with webhooks), you have:
GitHub Actions, still in beta, but which should make it possible to accomplishes this (registration here).
efforts made to look for a webhook-based alternative.
For instance: pyinstaller/pyinstaller issue 3579. But there are no clear answer yet.
Update Feb. 2020: this issue is now closed (GitHub Actions are very much the standard now)
As far as I can tell, GitHub has now restored the previous functionality and even documented it again: https://help.github.com/articles/about-email-notifications-for-pushes-to-your-repository
Related
Im using Jira with Bitbucket, and I wonder - can I somehow store info about that one or more revisions are related to some ticket, without writing ugly prefixes like ABC-123 in commit-messages?
The only other solution is to login to JIRA UI and create an issue link to the commit page in Bitbucket.
Obviously, this is somewhat more work than just adding ABC-123 in the commit.
Short answer: not really
The problem is that most version control systems don't allow you to store extra structured data related to a commit. The least common denominator is the commit message, so it tends to get used for all kinds of logically separate data, e.g. JIRA issue keys, change the status directions etc. The git notes feature might be used for this.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.
I want to implement something simple like /System/Workflows/Sample Workflow with the small addition of having multiple publishing targets (staging web and production web environment), so instead of the Approved state with the final checkbox set, i want to modify it to two states;
Approved for Staging
Approved for Delivery
only the Approved for Delivery should be final. I want to set a PublishAction for each of them but i don't know how to set the publishing target?
This is a very common issue that ultimately ties to how Sitecore works. Your question seems to indicate that you understand that only one state in workflow should be final -- that's great that you see that. There are ways to do this, but I would say some of them are not best practice. Also, as divamatrix mentioned, there are other custom approaches.
Deviate from best practice and mark Approved for Staging as Final and Approved for Delivery as Final. I do not recommend this. I'm mentioning this is a solution so you can see the full circle of what you can do. The issue with this is that if you log in as an admin, you can potentially publish to any target as well as other things. Generally, this is just not a good idea.
As divamatrix mentioned, there's a custom publishing provider by Alex Shyba on the topic. The article linked is the older approach. There's actually an update to that solution which seems to be the next best thing. That solution includes a custom workflow provider and some updates to the targets in Sitecore.
Another option is to de-couple workflow from publishing, which might sound drastic, but in theory makes sense. Basically, force content to go through all of worflow, then have a publish-only role that is the only one that can publish the content. From there, they can publish to the staging site and get stakeholder approval before publishing live.
UPDATE: As of Sitecore 7.2, there is a built-in mechanism to publish to a pre-production target.
Here's a link to everything you need to know: Alex Shyba's blog entry on custom publishing targets. I can verify that it all works because I've currently got a site in production that uses exactly what Alex outlines. Let me know if you have questions.
UPDATE: As Mark points out, this link is indeed an older solution. It will work, but Alex's part 2 link as posted by Mark is a better solution.
I recently joined a project team that is using TFS (I have happily avoided TFS until now). I am trying to determine if there is a way to require a story/defect reference to be associated with every commit comment?
With Tortoise/SVN it was easy to add a requirement for a reference number to be required with each commit. Personally, I like to track every commit back to a user story or defect, so I am hoping there is a way make this mandatory in TFS as well? I searched SO and Google, and haven't found the magic "key words", so if someone can point me in the right direction, it would be greatly appreciated.
Note: Stories and Issues are stored in other tools and not tied to TFS in any way.
Can it be done? Yes. Is it easy? Fairly easy. However, two caveats. Caveat number one: you're going to have to write code. Codeplex has some good examples here. Additional searches on codeplex and on the almighty Google will locate you more examples.
The big caveat here is that check-in policies are client-side. Once you develop the policy, it will need to be deployed to all developer workstations. If the policy isn't installed? It is ignored. While I'm a big fanboy of TFS, this is one oversight that I can't believe is still in place after three major version releases.
You could create a server-side check-in monitor that examines the check-in and determines if the story has been associated. However, it will not prevent the check-in, but you can use it to alert someone to resolve it after the fact.
Switch to a DVCS system like Git (see this article on pre-commit hooks) or Mercurial (see this other article on pre-commit hooks) which DO have server-side hooks that can be overridden to do validation checks. :-)
Yeah, I know, not really the answer you were looking for but it is an alternative solution to the problem that some other SO users might find useful.
With the DVCS type of system, you can have a separation between hooks that run on the local computer and hooks that run on the server when your commit is pushed back to the shared repository. That kind of concept does not have a corollary in TFS. It can make some things easier for your developers. For example, every changeset that was committed to our shared repository had to have a ticket number attached in the commit message. Local pre-commit hooks guarded against changesets getting created (in Mercurial) that did not have proper commit messages.
With TFS's support for GIT in an upcoming release maybe things will be easier in this regard.
When I check-in code, I sometime write very long, detailed checkin notes, other times I write very short ones (or no note at all). The longer notes tend to include information about why the change was made (business reasons, customer interactions, etc). However, I'm not sure if check-in notes are the right place for such detail. Most check-in notes I've seen tend to be short and simply reference a bug.
What is an appropriate level of detail for check-in notes?
Whatever your manager or company documentation tells you ;)
That being said, shorter is better. It's not the correct tool for lengthy documentation - your bug/feature tracking software is built for this and in most cases, can integrate with your source control.
Just enough so, when following the log few weeks later to have an idea about what hapenned.
I use these logs to check what has been done in the last day (or days) in the project I'm leading.
Shorter messages doesn't necessary mean better. Nor longer messages. Just keep in mind the goal of those comments: to give an overview of the activity on versioning system.
The right answer, I've found, is dependent on the needs of your organization. It sounds fuzzy, but the primary reason to provide detail for a code check-in is for context and understanding if that check-in needs to be reviewed or revisited. It might be incredibly verbose, or it may be remarkably simple.
In one company, our code check-ins would reference #+ticket-number. This mapped our SVN commits against a Trac ticket number, which held all of our details about a given issue or feature we were implementing. We referenced everything through Trac, so keeping our details in that form worked best for us.
For you, it depends on how you and your team work. I would base what info you keep in your check-ins on the need for the data, how often its referenced, and what happens if you lose context (i.e., have no idea why a change was implemented.)
Another consideration may be accessing those notes outside your code repository, which may not be the most effective mechanism for storing that information. Nonetheless, I find it's personal preference.
In my version-control experience, I tend to curse the ones that left no note at all, or a note that takes 5 minutes to dig through.
If you use your version control system to browse the history of a file to find a specific change, it's best to include a short comment on the why, and the what. The how is to go in the source code documentation.
Whenever I write a comment or a commit log message I ask myself "what will the next guy need to know? what are they likely to ask me about?"
Answering a question seems to be the easy way to keep comments brief and useful. It also avoids anti-documentation (rephrasing code, often in unintentionally ironic ways) or re-phrasing the metadata the vcs will be tracking anyway (added foo.java, tuesday change, new tag "bar-1-1-4")