ignore [no test files]

[mostafasolati]

This change removes the packages that have no test files by default. We still can see those package in verbose mode (-v) but seeing these lines in every test is annoying so I removed them by default.

[subtlepseudonym]

This seems like behavior that should be controlled by adding a flag (like --omit-ignored) rather than changing the default behavior.

[rakyll]

I agree with @subtlepseudonym that we should instead have a separate flag and shouldn't change the default behavior of "go test".

[mostafasolati]

This seems like behavior that should be controlled by adding a flag (like --omit-ignored) rather than changing the default behavior.

Okay I added a flag called -ignore and its default value is false

[subtlepseudonym]

@mostafasolati , if you're open to it, I have a few suggestions on the use of git that will make your work clearer.

[subtlepseudonym]

@mostafasolati you can find the git docs here

I've tried to summarize a few helpful points below --

• git add some_file.go makes isolating your changes a lot easier and won't add things like .idea/
  • This will also help if you want to add .idea/ to your .gitignore file, but don't want to commit the .gitignore
• git add -p . will give you even greater granularity, splitting things up into "hunks" and using an interactive mode to let you decide what to do with each hunk individually
• To unstage things you've added, use git reset
• Try separating commits into small, related changes
• Commit messages should indicate what that specific commit does to the codebase
  • use flag.Args instead of os.Args is a great commit message because it summarizes the commit succinctly
  • some changes isn't a very good message because I now have to look at the changes to know what it does
• If you commit something you didn't intend or otherwise want to update the commit, you can use git commit --amend, though this is only relevant if you haven't pushed your changes yet

Let me know if anything is unclear or unhelpful.

[mostafasolati]

@subtlepseudonym What does the "Some checks haven't completed yet" message mean?

[subtlepseudonym]

@mostafasolati I suspect you're getting that error from attempting to merge this PR.

Specifically, the error means that the ci/circleci: build check below has not completed successfully and github won't merge the pull request until it has. More generally, you can't merge this PR for two reasons: it hasn't been approved and you don't have write permissions.

[mostafasolati]

@mostafasolati I suspect you're getting that error from attempting to merge this PR.

Specifically, the error means that the ci/circleci: build check below has not completed successfully and github won't merge the pull request until it has. More generally, you can't merge this PR for two reasons: it hasn't been approved and you don't have write permissions.

Sounds wierd, how can I attempt to merge without permission?

[subtlepseudonym]

Sounds wierd, how can I attempt to merge without permission?

You can't, which is by design. This is rakyll's repo and, to my knowledge, they are the only one with write permission. They have the final say on whether your changes are accepted and merged.

[rakyll]

@mostafasolati please ignore the CircleCI, I can merge the change without it passing. I have been trying to set it up but the builds seem to be stuck. Please don't worry about it. If you can address the comments, I can merge :)

[mostafasolati]

.gitignore removed

[rakyll]

The filtering of arguments and flags were causing a few bugs and is harder for us to maintain due to the lack of comprehensive testing. Instead, I switched to an environment variable to make things easier to maintain. https://github.com/rakyll/gotest/issues/30