How can I set the test result path for Concordion? I'm using Java for Concordion and HTML as the markup language for the spec file.
Set the system property concordion.output.dir to the target output path.
Related
resource "aws_api_gateway_rest_api" "api" {
body = "${file("apigateway/json-resolved/swagger.json")}"
name = "api"
}
---------------------------------------------------------------------------------
Invalid value for "path" parameter: no file exists at apigateway/json-resolved/swagger.json;
this function works only with files that are distributed as
part of the configuration source code,
so if this file will be created by a resource in this configuration you must
instead obtain this result from an attribute of that resource.
When I try to deploy my API by providing the actual path to the API JSON, this is what it throws. Even though the file is there, even though I tried different paths, from relative to absolute, etc. It works when I paste the entire JSON in the body, but not when I provide a file. Why is that?
Since Terraform is not aware of the location of the file, you should specify it explicitly:
If the file is in the same directory, then use ./apigateway/json-resolved/swagger.json
If the file is one directory up from the directory you are running Terraform from, you could use ../apigateway/json-resolved/swagger.json
Alternatively, it is a good idea to use Terraform built-in functions for path manipulation: path.cwd, path.module, or path.root. More detailed explanation about what these three functions represent can be found in [1].
Provide a full path to the file by running pwd in the directory where the file is located (this works on Linux and MacOS) and paste the result of the command in the file function input.
Additionally, any combination of the points 2. and 3. could also work, but you should be careful.
There is also another great answer to a similar question [2].
NOTE: in some cases the path.* functions might not give expected results on Windows. As per this comment [3] from Github, if the paths are used consistently (i.e., all / or all \), Windows should also be able to work with path.* but only for versions of Terraform >=0.12. Based on the code snippet form the question it seems in this case an older version is used.
[1] https://www.terraform.io/language/expressions/references#filesystem-and-workspace-info
[2] Invalid value for "path" parameter: no file exists at
[3] https://github.com/hashicorp/terraform/issues/14986#issuecomment-448756885
Is there any way to use a relative file path for JSON schemas ?
Below mentioned syntax not work in vscode :
$schema = "file:///foo.schema.json"
And this one works :
$schema = "file:///c:/test/foo.schema.json"
If you have a scheme like file:, that forms a full (absolute) URI, instead of a (relative) URI Reference.
A full URI is supposed to mean the same thing everywhere, so it doesn't make sense to have a relative file path. Also note that file:///foo.schema.json is the same thing as file://localhost/foo.schema.json
To write a relative filename, use a URI Reference, like foo.schema.json. This will be resolved against a URI base — typically the URI of the document — to form the correct URI, even if the file moves on the filesystem.
For example, if you use this in a file at c:\test\main.json, then the Base URI will be file:///c:/test/main.json, and the URI Reference will resolve to file:///c:/test/foo.schema.json, which is correct.
See File Uri Scheme and Relative Files for more information on this.
I have a Java code using selenium where I have a properties file which is in JSON format with multiple values and I want to use that file in Jenkins. For that I am using "This project is parameterized" option where I am selecting "File parameters" option.
So My question is How to use the JSON format in Jenkins? Am I doing is correct and what changes we have to make in code for that?
Can anyone help on this?
The "File parameters" is not working in the way you think, it is not like Jenkins will parse file and give you something like key/value map - no.
What is it doing is follwoing , you basically upload file and then how you use it is up to you, so in other words, if that file is for you java code, set the path for that file using the JVM params (e.g. -DpropertiesFilePath = ${abc.xyz}) and then Jenkins will parse the ${abc.xyz} for you and you java code will have proper path to file.
Otherwise, if you want to use the properties inside that JSON file itself for jenkins job configuration needs, then you have to write Jenkins job using either DSL or Jenkinsfile, in which having full access to file you can use for example JsonSlupper and parse Json file and assign properties to stages or whatever you need in Jenkins job walkthrow.
I'm trying to define a coding standard for a project and I want to specify use of JSON Schema version 4.
However, from the offical JSON Schema website, if you follow the links for the Specifications, takes you to the github page, then into the Version 4 Draft at the IETF. This document explicitly states that it is an Internet-Draft document and says:
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Since there don't seem to be any versions of the JSON Schema that are anything other than Internet-Draft status, how should I reference this?
Edit: This is in a written project document, not within a JSON file itself. I currently have text like this:
Python Standards and Style
All Python Source Files MUST be written in
Python 3.x, specifically targeting Python 3.5.1 as the default Python
3 installation with Ubuntu 16.04 LTS.
All Python Source Files MUST
conform to the PEP 8 standard [footnote:
https://www.python.org/dev/peps/pep-0008/ ].
All Python Source Files
MUST pass a flake8 [footnote:
https://pypi.python.org/pypi/flake8/3.2.1 ] check before each delivery.
The checker MUST be set up to be ultra-pedantic and it MUST be
considered a unit test failure if the checker needs to change anything
on the checked in Source Files.
All Python Source Files SHOULD use
Docstrings conforming to the PEP 257 standard [footnote:
https://www.python.org/dev/peps/pep-0257/ ].
JSON Standards and Style
All JSON Source Files MUST be written in JSON Schema version 4
[footnote: https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04 ].
All
JSON Source Files MUST conform to the Google JSON Style Guide 0.9
[footnote: https://google.github.io/styleguide/jsoncstyleguide.xml ]
All JSON Source Files MUST pass a jsonschema [footnote:
https://python-jsonschema.readthedocs.io/en ] check before each
delivery. The checker MUST be set up to be ultra-pedantic and it MUST
be considered a unit test failure if the checker needs to change
anything on the checked in Source Files.
TOML Standards and Style
All TOML Source Files MUST adhere to v0.4.0 of the TOML standard [footnote:
https://github.com/toml-lang/toml ].
All TOML Source Files MUST be loadable
with the pytoml parser v0.1.11 [footnote:
https://github.com/bryant/pytoml ], without error.
All TOML Source Files SHOULD be
aligned at the left margin – i.e. do not indent sub-sections.
To me, the italicised footnote to the JSON Schema reference would count as citing an Internet-Draft document, which is explicitly stated as not appropriate in the excerpt I gave above.
Since there don't seem to be any versions of the JSON Schema that are
anything other than Internet-Draft status, how should I reference
this?
You do this:
{
"$schema":"http://json-schema.org/draft-04/schema#",
... // the rest of your schema
}
Just because a standard is in draft format doesn't make it any less a standard.
Now, you also have the option of authoring the schema without a $schema declaration and it will still be perfectly valid. If you do this and use the proper JSON schema draft v4 definition then this will be usable by all parsers supporting draft v4. However, the convention is to use the $schema declaration.
All JSON Source Files MUST be written in JSON Schema version 4
You don't want all JSON files to be schema-based - that's ludicrous. However, any schema files you do need you will have no choice from a documentation perspective other than to reference a version of the standard. And that version should be draft 4 even though it's a draft.
The alternative is to completely remove any reference to JSON Schema altogether, which is probably the route I would take.
Let's say that i have file /home/foo/myfile without extension. Is there option to add syntax setting into this file? In vim it's :set syntax=javascript. I know that in Sublime you can set default syntax color.
There's similar question Changing default syntax based on filename but there you set specific filename. I need to set it in file itself, since i have a lot of different files without extension.
The package ApplySyntax should be able to do what you want.
ApplySyntax is a plugin for Sublime Text 2 and 3 that allows you to
detect and apply the syntax of files that might not otherwise be
detected properly. For example, files with the .rb extension are
usually Ruby files, but when they are found in a Rails project, they
could be RSpec spec files, Cucumber step files, Ruby on Rails files
(controllers, models, etc), or just plain Ruby files. This is actually
the problem I was trying to solve when I started working on this
plugin.
Set your rules/filenames in the ApplySyntax.sublime-settings file:
// "rules" is a list (array) of checks that you want to make against
the file in the current view. A rule is either a regular expression
or a function. If using a regular expression, you can specify
whether you want it tested against the "file_name" or the first
line of the file (think shebangs and xml files). If the rule is a
function, you must provide the path to the file containing the
function and the name of the function to call. When this function is
called, the "file_name" will be passed to it as the only argument.
You are free to do whatever you want in your function, just return
True or False.
you can do this on the fly through the command menu (on OSX cmd+shift+p, windows ctrl+shift+p) then type what you need (e.g. javascript) and it will come up in the list set syntax: JavaScript.
Sublime will remember this until you close the file