This might be a basic github question, but I'm having trouble finding the right keywords to google because I don't know the terminology. Apologies and thanks in advance.
I've noticed with library dependencies in library.json, under "dependencies", there is often a github remote repo link with a version number after the #
For example
https://github.com/codewitch-honey-crisis/htcw_ili9341.git#1.0.0"
What is that exactly after the #? A branch? A release?
More importantly, how do I make my github repo expose these. Like, I want to make a 1.0.0 one now for htcw_ili9341.git but later I may want to make 1.0.1
Using the github website, and/or the command line, how do I go about this?
It would be really helpful if you explained as you went as well.
So you know where I'm coming from with this, I've been using github for awhile but only for the most basic things, and driving it all through VS Code for the most part, sometimes resorting to the web interface and only occasionally dropping to the command line, which I've done a handful of times to resolve merge conflicts. I'm not an expert, but not completely new to it either.
anything after # is never posted to the server. It's basically a comment in this specific instance.
Tech writers are going to edit text in JSON files via github in our project. Since they never used a IDE (and don't need to) we think about using the web GUI of github. We have a CI, but it would be very cool, if we could run a check before the commit gets done.
Example:
Step 1: tech writer opens in github the JSON file
Step 2: tech writer updates a string
Step 3: tech writer presses button to save the changes
Step 4: Some simple script executes and checks the content of this particular file.
Step 5a: Everything fine? Then commit - END
Step 5b: There is a syntax error. Show the error message to the tech writer.
Is this possible?
GitHub doesn't provide this functionality, and it's not likely anyone else does, either.
In order to do this, GitHub would have to have a non-bare repository on their servers and let you run an arbitrary script. Bare repositories are packed and can be much smaller than a full working tree, and even if GitHub had a working tree, it wouldn't necessarily be on your branch, which would delay the process. Running an arbitrary script is a security risk, and it's not guaranteed that your script would run fast enough for the process to complete in a reasonable amount of time. Your script would also need to run via the API, which has hard limits on response times.
There is GitHub Actions, which lets you do this, but that doesn't provide real-time checking like you want. It is appropriately sandboxed and single use so you can arbitrary scripts.
I should note that Git also doesn't provide real-time checking here: the best it can do is pre-commit hooks to prevent you from committing bad changes (if you've chosen to enable them).
I'm running a team of developers on a project and I constantly see this kind of commits:
Whenever I get about 5000 lines of code like this, i get quite frustrated
Is there any way to make github not show added whitespaces/newlines?
Set the URL parameter w=1 in the github url which enables the ignore whitepsace feature
Take a look at the difference between
https://github.com/renelink/..../9491a0ed3ae57f7b33386605d3f62f85eca8ae05
and
https://github.com/renelink/..../9491a0ed3ae57f7b33386605d3f62f85eca8ae05?w=1
But I guess the main problem is that the developers work on different OS and do not configure core.autocrlf.
I am working on a large project with a number of other developers.
We have implement JSHint which will throw an error when grunt build is run if the JavaScript does not pass the Lint.
I would like to know if it is possible to integrate directly with Github so that a Pull Request will not be allowed to be merged unless it passes in JSHint.
Is there a way or tool to do this?
You can't prevent pull requests from being merged; however, you can automatically run JSLint using Travis-CI, which will put a big red X on pull requests that do not pass JSLint. Hopefully this is enough to stop people from merging these pull requests.
This blog post gives a good introduction to running grunt tasks on Travis-CI.
There is a free way to do it too by lint-review
As #tbekolay said, it puts a red sign.
Also, you will see the problems as comments on the code wich is super cool.
But you can merge it manually.
At my work we currently use Aegis version control/SCM. The way we have it configured, we have a bunch of tests, and it forces the following things to be true before a change can be integrated:
The full set of tests must have been run.
All tests must have passed.
With test-driven development (TDD) these seem like sensible requirements. But I haven't heard of any way you can do this with any other version control systems. (We're not currently planning to switch, but I would like to know how to do it in the future without using Aegis.)
I would be interested in any VCS (distributed or not) that can do this, I'm also interested in any plugins/extensions to existing VCS that allow this. Preferably open source software.
ETA: OK, it seems like the usual thing to do is have VCS + continuous integration software, and running the tests is automated as part of the build, instead of as a separate step. If I understand correctly, that still lets you commit code that doesn't pass the tests, just you get notified about it -- is that right? Is there anything that would stop you from being able to integrate/commit it at all?
IMO you're much better off using a continuous integration system like CruiseControl or Hudson if you want to enforce that your tests pass, and make the build rather than the check-in dependent on the tests results. The tools are straightforward to set up, and you get the advantages of built-in notification of the results (via email, RSS or browser plugins) and test results reporting via a Web page.
Regarding the update to the question, you're right - VCS + CI lets you commit code that doesn't pass the tests; with most CI setups, you just won't get a final build of your product unless all the tests pass. If you really want to stop anyone from even committing unless all the tests pass you will have to use hooks in the VCS as others have suggested. However, this looks to me to be hard to deal with - either developers would have to run all of the tests every time they made a checkin, including tests that aren't relevant to the checkin they are making, or you'd have to make some very granular VCS hooks that only run the tests that are relevant to a given checkin. In my experience, it's much more efficient to rely on developers to run the relevant tests locally, and have the CI system pick up on the occasional mistakes.
With subversion and git you can add pre-commit hooks to do this.
It sounds like you need to look at Continuous Intergration (or a variant of).
Think Git has a hook on apply patch too.
Subversion and git both support this via pre-commit hooks.
Visual Studio Team System supports this natively via checkin policies.
I believe that Rational ClearCase also supports it, though I've never seen that demonstrated so I can't say for certain.
We use git and buildbot to do something similar, though not quite the same. We give each developer their own Git repository, and have the buildbot set to build any time pushes to one of those repositories. Then there is someone who acts as the integrator, who can check the buildbot status, review changes, and merge their changes or tell them to fix something as appropriate.
There are plenty of variations of this workflow that you could do with Git. If you didn't want to have someone be the integrator manually, you could probably set the buildbot up to run a script on success, which would automatically merge that person's change into the master repository (though it would have to deal with cases in which automatic merge didn't work, and it would have to test the merge results as well since even code that merges cleanly can sometimes introduce other problems).
I believe continuous integration software such as team city allow you to do pre-commit build and test. I don't know of any vcs that provides it directly...there may be some like the one you use but I'm not familiar with them.
You can also use pre-commit hooks in Perforce. And, if you're a .NET shop, Visual Studio can be configured to require "gated" checkins.
VSTS with custom Work Items, right? I don't see anything wrong with using this. Built in reporting. The choice to automate. Why not?
What I do here is following a branch per task pattern which lets you test the code already submmitted to version control but still keeping the mainline pristine. More on this pattern here.
You can find more information about integration strategies here and also comments about Mark Shuttleworth on version control here.
Most CI implementations have a mechanism to reject check-ins that don't meet all the criteria (most notably pass all the tests). They're called by different names.
VCS should do what they do best.. version source code.
TeamCity - Pre-tested commit
TFS - Gated check-ins