-
Notifications
You must be signed in to change notification settings - Fork 630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unit test input files are verified during make verify-units-inputs
#1909
Unit test input files are verified during make verify-units-inputs
#1909
Conversation
d1c82b9
to
0eb7f59
Compare
6210e77
to
a5eb81e
Compare
We had to change some input.pp files to that they confirm to the puppet syntax. Due to those changes some tags have changed.
In th testing.mak, using a phony target will execute the target all the time. However for unit test input file checking, we only want to verify inputs that have been modified. An empty target construct in Makefile is suitable for that. Also update the gitignore file to ignore the empty target files.
Unfortunately having bmake build problems in fedora build
The line of the makefile in the fedora container looks like this
I would not be surprised if the bmake does not have the define (metaprogramming) feature . Do you know @masatake ? |
@masatake This PR is about 70% there of what I had originally in mind.
Regardless, I think this PR is mature enough to be reviewed. Let me know if this approach is acceptable to you. |
The puppet error messages fixed from the input.pp files are:
|
makefiles/testing.mak
Outdated
$(shell dirname $(path))) | ||
VERIFY_PUPPET_TEST_DIRS_TARGETS := $(PUPPET_TEST_DIRS:%=%/.input.pp.verified) | ||
|
||
#TODO: We shuold make this an empty target rather than a phony target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is not applicable anymore. Should be deleted
makefiles/testing.mak
Outdated
@@ -88,6 +88,31 @@ slap: $(CTAGS_TEST) | |||
--with-timeout=$(TIMEOUT)"; \ | |||
$(SHELL) $${c} $(srcdir)/Units | |||
|
|||
# TODO: Possibly the bmake does not support the metaprogramming similar to gnu make. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather avoid using non-portable Make stuff if possible, assuming the rest of our makefiles work with BSD make. Here it seems fairly easy to simply make it the content of the target itself, it doesn't seem very important to build target, nor even only build once -- rebuilding seems unlikely and innocent enough.
So, I guess I'd just do something like this (not tested at all, just for the argument):
verify-units-inputs: verify-units-inputs-puppet
verify-units-inputs-puppet:
find $(srcdir)/Units/parser-puppetManifest.r -name expected.tags | $(SED) 's%/[^/]*$$%%' | while read -r dir; do \
puppet apply --noop "$$dir/input.pp" || exit 1; \
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see couple of more problems with this approach in the comment.
- One cannot use the make job control mode (
-j
) forverify-units-inputs
. Allinput.XX
file verification has to be done serially. - What @b4n mentions: Cannot avoid re-execution. What I have seen, re-execution can be quite expensive. The input language toolchain does not necessarily have fast startup time. In this change, puppet runs take several minutes if executed serially. Consider the need to run interpreters, compilers for each
input.xx
file. Hence, for fast test and development time both (1) and (2) are important. - The complexity of the testing.mak is bound to grow. ctags supports 10's of different input languages. Each having their
verify-untis-inputs-<language_name>
target is not easy to maintain. Compared to that, the conditional ofif !USING_BMAKE
could be acceptable.
These three are important drawbacks.
With using metaprogramming, we gain on all 3 of them. (See my next push to this PR) . What we lose is missing verify-units-inputs
target in BSD builds. That will not prevent BSD platforms from building and using ctags. Developers on BSD only won't be able to execute make verify-units-intput
locally, if they are submitting PRs from BSD platforms.
I have not done development on BSD before. But that does not seem like a big blocker either https://unix.stackexchange.com/a/127955/212862
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, and you're right that this is probably not a critical enough part of the build system that it can't have its own requirements. Also, we can remember that GNU make is fairly portable by itself, and although not everybody likes it, it is usually possible to get it on most systems; AFAIK it's available on all BSDs under gmake
, yet probably not in a stock installation.
Anyway, given your arguments I only have one concern now: we should check for GNU make, not against BSD make. There are many Make implementations that aren't compatible with GNU make, and most Make implementations don't have those metaprogramming features. So unless somebody feels like tesing every single Make implementation around and see what exact subset it supports, I strongly suggests we have a whitelist instead of a blacklist, and only have GNU make in it at first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS: moreover, most Make implementations are installed as make
, not as other aliases like bmake
, gmake
, pmake
or whatnot. Checking for the name of $MAKE
is not a solid way of cheking which Make implementation is in use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the input. I agree on both aspects. The whitelist-blacklist and checking the name of $MAKE. I will hold off on the implementation, though. @masatake mentioned that he will implement this in /misc/units script. If anything changes, I am more than willing to address your comments in this PR.
The makefile now uses two nested defines to fully parameterize the unit test input file parameterization.
1) Consume the stdout of the verification command. Prints too much to the console. Useful information to debug will be printed via the makefile echo and also the std err anyways 2) Add a clean-verify-units-input command.
Set the clean dependencies. Get the extension parameter and use it correctly in the define block Install further test requirements in centos container.
jq comes from epel-release.
make check
( For now only puppetManifest files) make check
make check
make verify-units-inputs
In the latest version of this PR (16 commits) we enable input language checking while
With this PR, we check not only the puppet files but also the json files. |
I would like to move the logic to misc/units though it makes running parallel impossible. I will borrow many codes from this pull request. However, I will design the infrastructure very differently based on my experience implementing misc/units, the backend of make units. |
I always need help for documentation. Especially #1737. All unclosed issues you opend will take time to solve. All the items are cross-parser issues. (Therefore, they are important.) |
@masatake my biggest priority now is to improve ctags experience with puppet code. I have opened several tickets that should improve exactly that. I would be very interested to help with that purpose. Unfortunately, I do not think I have the bandwidth to contribute to many other exciting areas in ctags. |
@ahakanbaba, I see. |
Conceptualy derived from a pull request, universal-ctags#1909 sent by @ahakanbaba. A example session: $ bash misc/units verify-input Units misc/verifiers .. Category: ROOT ------------------------------------------------------------ simple-json.d/input.json with jq valid zephir-simple.d/input.zep with zoop unavailable Summary ------------------------------------------------------------ #valid: 44 #invalid: 19 #skipped (known invalidation) 1 #skipped (verifier unavailable) 1 Unavailable verifiers ------------------------------------------------------------ zoop You can specify verfiiers to use with --verifiers= option. $ dash misc/units verify-input --verifiers=jq Units misc/verifiers .. Usage: A test case developer puts "verfier" file to one's test case directory or one's category directory. Put a name of verifier to the file. If the file is at a category directory (Units/*.r), the verifier specified in a file is used for verifying all input files under the category. Put "verify" file in a test case directory to override the verifier specified in the category directory. "KNOWN-INVALIDATION" is a special verifier. If the input is kept invalid intentionally, specify the verifier. A verifier developer writes verifier-foo file and puts it to misc/verifiers. Shell is suitable for writing the file. The execution bit of the file must be set. Here, "foo" is the name of verifier which may be specified in "verfier" files under Units. The file name is made a bit redundant. misc/units runs a verifier command in two different modes. If "is_runnable" subcommand is given as the first argument, return 0 if the verifier is ready to run. A verifier may depend on external tools. If the verifier cannot find the external tools in the runtime environment, the verifier exits with non-zero. misc/units never runs the verifier if the verifier exits with non-zero for the subcommand. If "verify" subcommand is given as the frist argument, the script do verify the input file passed as the second argument. It returns 0 if the input is valid, or non-zero if it is invalid. TODO: The above memo should be written in docs/testing.rst. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
verify-input target derrived from #1909
Units/parser-puppetManifest.r/puppet-append.d/verifier is very special. About puppet-append.d/verifier, the puppet verifier reports this input as "invalid" because `+=' operator is obsoleted in puppet5. @ahakanbaba in universal-ctags#1909 reported and proposed a fix for this already. However, @masatake kept this as is for following reasons: - valid in puppet4, - testing KNOWN-INVALIDATION special verifier, and - testing '#' comment in a verifier file. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Units/parser-puppetManifest.r/puppet-append.d/verifier is very special. About puppet-append.d/verifier, the puppet verifier reports this input as "invalid" because `+=' operator is obsoleted in puppet5. @ahakanbaba in universal-ctags#1909 reported and proposed a fix for this already. However, @masatake kept this as is for following reasons: - valid in puppet4, - testing KNOWN-INVALIDATION special verifier, and - testing '#' comment in a verifier file. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Closing in favor of #1921 |
Units/parser-puppetManifest.r/puppet-append.d/validator is very special. About puppet-append.d/validator, the puppet validator reports this input as "invalid" because `+=' operator is obsoleted in puppet5. @ahakanbaba in universal-ctags#1909 reported and proposed a fix for this already. However, @masatake kept this as is for following reasons: - valid in puppet4, - testing KNOWN-INVALIDATION special validator, and - testing '#' comment in a validator file. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Introduce puppet verifier (derived from #1909)
This is an early work in progress.
I am sending this PR out to discuss the implementation approach for incorporating the verification of the unit test input files to make check.
I have used some makefile metaprogramming. http://make.mad-scientist.net/the-eval-function/ I am by no means a makefile expert. So let me know please if there is a better approach to this.
Some missing pieces: