We are using the git-commit Codefresh step to push updates during a build. We use husky and have pre-commit hooks that rely on yarn. This fails within the step because the dependency is missing.
How should we handle these hooks?
Here is the current step configuration:
push_snapshots:
stage: deploy
title: Commit and push snapshot updates.
type: git-commit
working_directory: ${{clone}}
arguments:
repo: "${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}"
git: github
commit_message: Update snapshot post infra deploy
add:
- "./tenants/*/snapshot/*"
when:
steps:
- name: deploy_infra
on:
- success
and our .husky/pre-commit looks like:
yarn lint-staged
We've tried a couple of things:
Looked for a way to pass the --no-verify flag, but it looks like the only flag supported in the step is --allow-empty, and there is no way to pass arbitrary flags
Tried to override the image with a custom image (that extends git-commit:1.0 and then adds npm and yarn). That image was not actually read by the step, the step just used its usual image.
Related
I am rewriting my CircleCI config. Everything was put in only one job and everything was working well, but for some good reasons I want more structure.
Now I have two jobs build and test, and I want the second job to reuse the machine exactly where the build job stopped.
I will later have a third and four job.
My desire would be a line that says I want to reuse the previous machine/executor, built-in from CircleCI.
Other options are Workspaces that save data on CircleCI machine, or building and deploying my own docker that represents the machine after the build job
What is the easiest way to achieve what I want to do ?
Currently, I have basically in my yaml:
jobs:
build:
docker:
- image: cypress/base:14.16.0
steps:
- checkout
- node/install:
install-yarn: true
node-version: '16.13'
- other-long-commands
test:
# NOT GOOD: need an executor
steps:
- run:
name: 'test'
command: 'npx cypress run'
environment:
TEST_SUITE: SMOKE
workflows:
build-and-test:
jobs:
- build
- smoke:
requires:
- build
Can't be done. Workspaces is the solution instead.
My follow up would be, why do you need two jobs? Depending on your use case, pulling steps out into reusable commands might help, or even an orb.
I would like to use the machine executor so that I can run some component tests with docker-compose. My workflow fails on the checkout step and throws this error: Making checkout directory "/opt/my-app" Error: mkdir /opt/my-app: permission denied
Here is the yaml for the component_test stage in my workflow:
component_test:
machine: true
working_directory: /opt/my-app
steps:
- checkout
If I use docker instead of the machine executor then I don't get any permission issues:
component_test:
machine: true
working_directory: /opt/my-app
steps:
- checkout
But, I'd like to be able to use docker-compose and thus need to be able to run the machine executor. Has anyone seen a permission issue like this before?
You need to either change the working directory into something in /home/circleci or just exclude it complete as it's optional.
Right now, the circleci user runs the checkout step, which doesn't have permission to git clone to the working directory you choose.
Also, I wouldn't use machine: true as that is deprecated. Specify an image: https://circleci.com/docs/2.0/configuration-reference/#available-machine-images
I'm trying to create two different actions within travis.ci. The first action is to execute a script on every push on every branch. This is currently working as desired. The second is to trigger a different script only when git push origin --tags. In short:
Execute script1 always (currently working)
Execute script2 when tags are pushed
Here is what I'm trying:
language: python
python:
- 3.7
matrix:
include:
- python: 3.7
sudo: true
install:
- pip install -r requirements.txt
script: # Always want this to happen
- invoke package
branches:
only:
- master
- /^x\/.*/
deploy: # Want this to occur on git push origin --tags
provider: script
script: invoke release
on:
tags: true
The deploy section is not being triggered, and I can find no evidence of the invoke release script being invoked.
Update:
It may be due to the way I'm pushing tags..? I'm seeing this log in travis now:
Skipping a deployment with the script provider because this is not a tagged commit
Solved it from this github issue. Changed the deploy section to this:
deploy:
provider: script
script: invoke release
on:
tags: true
all_branches: true
but had to remove the branches section. Deployment script was invoked, nonetheless.
Circle CI does these and more, before it gets to your actual Java/Ruby/Python/etc build:
Starting the build
Start container
Enable SSH
Is there a way of inserting a custom command at that early stage? Circle.yml seems to be where you would specify things like that, but the documentation doesn't detail things that can be inserted into the earlier stages/steps.
In CircleCI 1.0, there's several phases, and steps in those phases, that you can run commands.
The absolute earliest step is:
machine:
pre:
- echo "Some command"
Many components in the build aren't ready by this step though, including git clone. In that case, you can also run commands after the machine phase and before dependencies.
machine:
post:
- echo "Probably the better place to run early commands."
dependencies:
pre:
- echo "Run commands before any inferred dependency commands."
More on how phases in circle.yml work can be found in the CircleCI 1.0 Configuration Doc.
-Ricardo N Feliciano
Developer Evangelist, CircleCI
I'm trying to trigger a build task when a commit is tagged, however, I cannot make it work, ideally, this exec the task and create the build folder on the release folder only not into the branch.
Notice I'm not trying to deploy to any external.
My config looks like this
test:
override:
- yarn test
deployment:
release:
tag: /v[0-9]+(\.[0-9]+)*/
owner: ORGNAME
override:
- yarn run build
Any ideas???
From https://circleci.com/docs/1.0/configuration/#tags
Normally, pushing a tag will not run a build. If there is a deployment configuration with a tag property that matches the name of the tag you created, we will run the build and the deployment section that matches.
After adding the tag to a task in the deployment section, the build will run as normal. If you don't want to do anything specific for that tag, you don't add a command.
So:
compile:
override:
- yarn run build
test:
override:
- yarn test
deployment:
release:
tag: /v[0-9]+(\.[0-9]+)*/
owner: ORGNAME