I am trying to clone a third private repo, only my github user has read access.
I added a user key from ssh keys section on circleci
I confirm circleci key was added to my user
I put that fingerprint on my config.yml ssh keys
When try to clone pipeline give the error:
ERROR: Repository not found.
fatal: Could not read from remote repository.
I rerun build with ssh access.
Try to run clone to private repo and i get the same erro.
I dont know if i am missing something.
I try to automate cloud run deployment with the cloudrun orb, but circleci throws the following error:
# Error calling workflow: 'build_and_deploy_to_managed_workflow'
# Error calling job: 'build_and_deploy'
# Cannot find orb 'cloudrun' looking for command named 'cloudrun/init'
#
# -------
# Warning: This configuration was auto-generated to show you the message above.
# Don't rerun this job. Rerunning will have no effect.
# false
# Exited with code exit status 1
My config looks like this:
jobs:
build_and_deploy:
docker:
- image: 'cimg/base:stable'
steps:
- checkout
- cloudrun/init
- cloudrun/build:
tag: 'gcr.io/ml-webpage-264418/personal-webpage'
- cloudrun/deploy:
image: 'gcr.io/ml-webpage-264418/personal-webpage'
platform: managed
region: us-east1
service-name: personal-webpage
unauthenticated: true
args: "--set-env-vars: [aws_secret_access_key=${aws_secret_access_key},aws_access_key_id=${aws_access_key_id}]"
- run:
command: >
# A simple example of how a deployed managed service could be
verified or further tested.
# This step will send request our "API" and fail if there is
unexpected output.
GCP_API_RESULTS=$(curl -s "$GCP_DEPLOY_ENDPOINT")
fi
name: Test managed deployed service.
orbs:
gcp-cloud-run: circleci/gcp-cloud-run@1.0.2
version: 2.1
workflows:
build_and_deploy_to_managed_workflow:
jobs:
- build_and_deploy
Can anyone help?
FOLLOW-UP: I have submitted a documentation PR that explains how to fix the issue now. https://github.com/circleci/circleci-docs/pull/4225
Hi all, I feel like I’ve got a fundamental misunderstanding of the purpose of pipeline parameters, and perhaps more of the CircleCI product.
A common thing that I did with Jenkins was have a job that, when run manually, would require selecting a parameter before the build.
This was handy for things like:
From what I understand, pipeline parameters (as distinct from orb parameters, or job parameters) are intended for the same purpose. In fact the API documentation seems to suggest that this is possible.
Furthermore, pipeline parameters don’t require a default option. The documentation specifically says:
If not present, the parameter is implied to be required.
Required where? I can’t find anywhere to actually use these.
When I pushed a pipeline with a parameter with no default, I expected to get the option to input this, but instead I was met with an error message about an invalid configuration, despite this being a documented as valid. When I added a default, rather than getting the option to run a pipeline with a specific parameter, CircleCI just unconditionally builds with the default every time.
From all of this, I feel like my mental model of CircleCI’s abilities does not align with the reality. Given that my mental model is informed by the documentation, API schema, data model, and UI, this puts me in a strange place when planning usage of the product, one where I have to second-guess everything I’m told about it.
Some clarity from the product team would be greatly appreciated.
Hi all, we’ve been using CircleCI on my team for about a year now, having switched from Jenkins. One of the things we understood about CircleCI was that it was both a CI and CD tool.
There are a number of requirements for reliable delivery, but one of the core requirements for most automated deployments is strictly ordered deployments.
This means that if you push changes A and then B (ordered that way in git history), then B will never deploy before A. There are nuances to this, some systems may coalesce A and B into the same deployment, some may define critical regions such that A and B can run in parallel for most of the build but get strictly ordered for the parts with side effects, and so on, but the core premise is that you can’t deploy in the wrong order.
This is critical for anything that deploys schema changes or does data migrations, but is typically a very useful property to have in all circumstances. It’s essentially table-stakes for a continuous delivery product.
Jenkins, for all its faults, does a pretty good job at this, and it was never something that required any thought from us. In ~6 years of operating Jenkins, this was never an issue we encountered.
Unfortunately CircleCI doesn’t have this. We were pointed towards the Queue Orb, which has helped us with the transition to CircleCI, but with our team growing and deployment velocity increasing, the race conditions in the orb and lack of flexibility around critical sections in deployments, we’re starting to have more and more issues of deployments going out in the wrong order. Also because the queueing is implemented in build, we pay build minutes for the time our builds queue, which is starting to become a significant proportion of our build time bill.
We’ve attempted to speak to our account manager about this, but after a few emails back and forth he went silent on us, and hasn’t responded to an email in months. The answer I always get from CircleCI support is a link to their “ideas” board, which isn’t a great sign for critical product features.
So I was wondering, how do others solve this?
How do you ensure your deployments go out in-order?
How do you enable queueing builds?
Is it possible to get around queueing while being billed for build minutes?
Are there alternative services that get this right?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
Can be closed.
There was en error in the documentation. Should be gcp-cloud-run instead of cloudrun.
Submitted PR:
I assume you are talking about an image maintained by the PostgreSQL team, so CircleCI employees would probably not have much input on this one. Can you use the one that @mbklein has indicated?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
I imagine I could, this is all new for me. Just seemed odd as the Alpine version had always been added previously to the CircleCI list. CircleCI seems to maintain a library of the different images.
Looking at the docker link - they do have an Alpine 11.7 - so in my config.yml file for CircleCI - would I just use this @mbklein
- image: docker/postgres:11.7-alpine
Seems almost too basic?
That didn’t work… have to read up some more on it. @circlecibeginner any tips?
I’ll give it a try to see if I can get it to work.
YAML doesn’t make this easy
docker:
- image: foo
- blork: bar
makes a map with a key pointing to a list, but
docker:
image: foo
blork: bar
makes a single map with three keys, with the docker key pointing to null.
It’s not at all intuitive :-/
Anyway, glad you’re unblocked
-Gordon
That’s absolutely the way to do it. You can specify any container as repo/image:tag (for images hosted on Docker Hub) or server/repo/image:tag (for images hosted elsewhere). I don’t know that there’s anything special about CircleCI’s images other than being officially supported.
Hmm ok I’ll have to check it again, as it couldn’t connect, so some weirdness going on or I’m missing something.
My tests run fine locally, but in CircleCI I get this error “Cannot find module ‘shared-data-model’” which is one of my Yarn workspaces.
The stack trace of the error points to Resolver.resolveModule (../node_modules/@jest/core/node_modules/jest-resolve/build/index.js:276:11)
Jest 25.1.0
Yarn 1.22
Node.js 12.16
Any ideas what could be causing this? Thank you
Hello @danpalmer!
Pipeline parameters actually behave similarly to how templating languages like Jinja2 or Mustache do - The << pipeline.parameters.parameter_name >> entry is replaced by the value of the parameter within the configuration file itself.
This is typically used in conjunction with the API to pass values along to the configuration, and there isn’t currently a way to define these within CircleCI itself beyond the default value of the parameter.
If the default value is missing, and it’s not passed along via the API, we consider the value required, and will fail the job since it isn’t present.
Happy to answer any other questions you might have 
Hi, running on 0.1.6949+d951526, when i execute:
circleci build --job test -e FOO1=BAR1 -e FOO2=BAR2
the env vars FOO1 and FOO2 are not accessible in the build, executing env as part of the build i can see:
[FOO1=BAR1,FOO2=BAR2]
DOCKER_VERSION=18.06.3
HOSTNAME=c48870140fea
SSH_AUTH_SOCK=/tmp/circleci-692488189/ssh_auth_sock
CIRCLE_WORKING_DIRECTORY=~/project
....
Thanks!
I get the same error as: Apt-get update on circlecI/classic - GPG error: Signature verification error
I’m using ubuntu-1604:201903-01. Is there any newer image? I can’t find anything in the docs 
In this workflow, we have audit as non-blocking because it has false-positives sometimes and we want the option to ignore it in case we have a high priority deployment. However, unlike what this shows, the prod-push job has run successfully (I can see it in the “jobs” panel.) This is a regression, as it definitely used to work. Unfortunately, we cannot trigger the “hold” steps because the UI doesn’t think it’s ready.
I figured out the problem. I am using typescript CLI tsc to transpile my module from /src to /dist, and I wasn’t running the transpile step on CI to generate the /dist folder, so when it tried to find the entrypoint of the module dist/index.js there was nothing there. Once I ran this step in CI it worked as expected.
