Apparently there are two ways to configure scrutinizer-ci to use custom phpCodeSniffer standards. The documentation only mentions phpcs use in "build" node and it isn't clear if they do different things or if one is preferred over the other.
Docs reference: https://scrutinizer-ci.com/docs/tools/php/code-sniffer/
What's the difference between running the checks inside "build" or "checks"? Should I use both?
checks:
php:
custom_coding_standard:
ruleset_path: 'ruleset.xml'
build:
tests:
override:
- 'phpcs-run --standard=ruleset.xml'
The official answer was to use phpcs-run.
build:
tests:
override:
- 'phpcs-run --standard=ruleset.xml'
The phpcs-run wrapper retrieves the latest version of phpcs on every build. Otherwise a preinstalled version of it is used. So usually the best way of running phpcs is using the wrapper in the build section.
Related
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I'm trying to run cypress on CircleCI, but I can't find any good guides on how the "orb" works other than this: https://circleci.com/orbs/registry/orb/cypress-io/cypress
In my config.yml file, this is the only configuration that I can get to work on CircleCI
version: 2.1
orbs:
cypress: cypress-io/cypress#1
workflows:
build:
jobs:
- cypress/run:
executor: cypress/browsers-chrome69
browser: chrome
This runs all the tests, and that's basically all I need. However, I think it's running on chrome version 69, which is really old. When I try to make it any other version of chrome, the executor is not recognized.
How do I set the chrome browser version?
Also, it would be nice to have more control over which tests to run, rather than simply run them all. How do I do that?
Any references to good guides for cypress + circleci would be appreciated.
Refer to the list of prebuilt containers here and replace executor with one of the options in the "Base Image" column https://github.com/cypress-io/cypress-docker-images/tree/master/browsers#cypressbrowsers
In addition, refer to the circle.yml in the Cypress Real World App for a reference of how the executor is composed.
I actually found the answer to this question already, and just want to document my finding.
First of all, this problem is not specific to building the leveldown module for Windows PouchDB. From what I have read online, it is a fairly common problem.
It has to do with the fact that nw-gyp somehow forgot the target version of NW between the nw-gyp configure and nw-gyp build command. When this happens, a TyperError: Invalid Version: undefined would be thrown.
The solution is actually very simple, all you need to do is to set --target= again when you do nw-gyp build, like this:
nw-gyp configure --target=0.47.0
nw-gyp build --target=0.47.0
First of all: I am somewhat new to cloud build. Compared to previously used methods, I find it a wrenching, unripe and fairly annoying framework. Endless time is spend getting builders to work that supposedly work out of the box (like the helm builder for example), and it's limitations are astonishing and frustrating. Perhaps the following problem is a good example:
I would like to build and push a docker image. According to the documentation, the images to be pushed to the docker repository at the end (I'm using GCR for this) reside in the following configuration section in my cloudbuild.yaml file:
images:
- 'eu.gcr.io/$PROJECT_ID/my-project:${_TAG}'
- 'eu.gcr.io/$PROJECT_ID/my-project:latest'
I can set the _TAG substitution manually by using the section:
substitutions:
_TAG: x.y.z
but that means I have to manually fix the version number in this file every time. Worse still: if I branch out, I need to maintain the version number all the time. I have a python project in this case and it uses setuptools, the version is naturally contained in the setup.py file and I can parse it out with no problem. Attempts to parse the number into a specific file and use $(cat VERSION) in the images section fail, because the system claims it can't substitute the $(cat VERSION) part. So how can I overwrite the _TAG variable inside of another build step such, that it appears correct in the 'images' section?
If you are using triggered builds from Cloud Source Repositories, GitHub, or Bitbucket you can tag your commit and use the $TAG_NAME default substitution variable.
images:
- 'eu.gcr.io/$PROJECT_ID/my-project:$TAG_NAME'
- 'eu.gcr.io/$PROJECT_ID/my-project:latest'
On the other hand if you are using the Cloud SDK to submit the Cloud Build build you can provide values with the --substitutions argument:
gcloud builds submit [SOURCE] --config config.yaml --substitutions _TAG=x.y.z
Also I believe you would find this GitOps-style continuous delivery with Cloud Build tutorial very helpful. It explains how to create a continuous integration and delivery (CI/CD) pipeline on Google Cloud Platform using Cloud Build.
You can tag your image with several tags using cloudbuild.yaml and define the Docker build step with:
steps:
- name: gcr.io/cloud-builders/docker
args:
- build
- '--no-cache'
- '-t'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
- '-t'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest'
- .
- '-f'
- Dockerfile.prod
id: Build
And resulting images with:
images:
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest'
While setting up a deploy pipeline for optimised builds of a server application, I ran into some trouble getting the GHC options right with stack-1.6.5.
In particular, from the docs it doesn't get clear to me how the various ways to specify GHC options work together and when and how they are applied.
As far as I can tell, there are X ways of specifying GHC options:
globally as ghc-options: in ~/.stack/config.yaml and/or /etc/stack/config.yaml, per package or with "$locals", "$targets" or "$everything"
in the project stack.yaml file, per package or with "$locals", "$targets" or "$everything"
in the project package.yaml/.cabal file, globally or per target
in a dependency stack.yaml/package.yaml/.cabal files
on the stack command line via --ghc-options
and there is the apply-ghc-options: setting locals/targets/everything in stack.yaml and ~/.stack/config.yaml and/or /etc/stack/config.yaml
I'd like to know which options are applied in the different build phases snapshots/locals/targets in which order and in which cases they are additive or override options given elsewhere.
good question, this is not adequately documented. These tend to be additive. Most of the logic for this is here: https://github.com/commercialhaskell/stack/blob/657937b0ac5dbef29114b43e9c69e2b57198af85/src/Stack/Build/Source.hs#L131 . Here's the order, where later items in the list come later in the options provided to ghc:
Options specified in the package.yaml / cabal file.
$everything in ghc-options in stack.yaml
$locals in ghc-options in stack.yaml
$targets in ghc-options in stack.yaml
Special options like -fhpc (--coverage) / fprof-auto -fprof-cafs (--profile) / -g (--no-strip).
Options specified via --ghc-options on the CLI
There is currently an issue where $everything / $locals / $targets ghc-options specified in .stack/config.yaml are not additive. Instead they are currently shadowed by the project stack.yaml. There is a PR fixing this, it will probably get merged at some point: https://github.com/commercialhaskell/stack/pull/3781