I have got a requirement to install Pre-Commit hook in Atlassian Stash(v3.11.6) for PMD, Checkstyle and Findbug to prevent commit, if the code changes does not meet the requirements. Could you guide me on where to get the hook and how to proceed further?
Related
Does enyone know how to clear cache of remote repository in Artifactory for loading artifacts (for example from maven repo) as well as in clean repository?
I tryed to find in Artifactory plugins, I found cleanup plugin but it cleans all repositories according description but I have to clean exact repo
Zap Cache is the option available with the repository itself, by design, to achieve this requirement.
Several builds, like this one, fail when executing cabal check:
++cabal check
These warnings may cause trouble when distributing the package:
* 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
However, most of the other builds in the matrix do not fail after this check.
I'm using the complex Travis configuration suggested at the stack docs, and this is the Travis configuration specific for the project I'm trying to get on CI.
Any ideas on what might be causing this behavior?
There are two types of build in your travis config:
Stack based build
Cabal based build
If you follow the script code, you will see that only Cabal based build has the command cabal check in it. That will explain why all of your Stack based builds are working fine. Now, let's see the cabal check command line in detail:
cabal check || [ "$CABALVER" == "1.16" ]
So, if your installed cabal version is 1.16, it will ignore the output of cabal check and that command is treated as a success. And infact, that's what is happening. Only one Cabal based build job is success in your travis, because it's version is 1.16.
I have a query on how others accomplish this and what, if any, the best practices are. I have an application that comprises three packages and they are setup in Bamboo for CI/CD.
The issue I am experiencing is that of how to automate the update of the package version on each build, e.g. npm version patch to bump the package version.
What I would like to know is how other accomplish these, I have thought about manually running npm version patch but that is not ideal and would be prone to errors (eg. forgetting to run this). I had also thought of adding a step in Bamboo to run npm version patch during the build but Bamboo clones the repository with out remotes and there unable to commit the change, otherwise every build would be the same version and still no better off.
An example is that we have a package which is an Electron application and when the build runs generates an MSI and .yml file for the auto updater, without incrementing the version the MSI will always be the same version and therefore the auto update would not work.
So what are the strategies for automating the version of an npm package for each build? What do others do in similar situations?
I would like to use pre-commit hook in gitlab. I doing everything like in documentation: https://docs.gitlab.com/ce/administration/custom_hooks.html
In custom_hooks directory I've created pre-commit file with folowing content:
#!/bin/bash
exit 1
Hook is never triggered, couse i can commit.
When i do the same with pre-receive hook - everything works good.
If Gitlab doesnt't let to use pre-commit hook?
As explained in Customizing Git - Git Hooks, a client-side hook won't be used on the server.
I explained before why it is not possible to include hooks in a clone:
"why it is not possible to git add .git/hooks/my-hook"
"Any way to put my hook to github repo?"
Since GitLab 7.5, you can set custom Git Hooks for server-side hooks.
Git natively supports hooks that are executed on different actions. Examples of server-side git hooks include pre-receive, post-receive, and update
Normally, Git hooks are placed in the repository or project's hooks directory. GitLab creates a symlink from each project's hooks directory to the gitlab-shell hooks directory for ease of maintenance between gitlab-shell upgrades
i've a repo with master and branch1. I'm writing test in branch1 with mocha / chai and i've changed the package json (forked a repo and maded some changes to it), but Travis seems to build still the old one, even if i changed my package.json. I've just forked and replaced the version in the package.json with the name of the repo (like everytime).
Anyone have experienced something similar? I'm missing the right way to make Travis build the package.json that is in the Pull Request where i'm working?
just trying to clarify some things in your question :)
Are you submitting a pull request to the upstream repo that you forked from, and wanting the upstream repo's Travis integration to build your code?
If so, it may be that the upstream repo's maintainer doesn't have the "Build PR" setting turned on in Travis for their repo. You could ask them. See this question for more details. Or maybe your PR can't be merged, as described in the Travis docs.
Or are you working on a branch within your own repo, which you forked from upstream?
If so, you need to set up Travis integration yourself on your own forked repo.
I solved my problem specifing in the package.json the commit id of the node module. Probabily not the best way to accomplish this, but the test passed now.