I tried to follow this guide on deploying an app on OpenShift from my private repository on GitLab. I tried using an SSH authentication key as a deploy key, GitLab personal access token with api scope and entering my GitLab credentials directly.
I've been failing at the step of adding annotation with repository URI to the secret using this command.
$ oc annotate secret/mysecretname \
'build.openshift.io/source-secret-match-uri-1=https://gitlab.com/username/reponame.git'
I'm getting the following error as a result.
error: at least one annotation update is required
See 'oc annotate -h' for help and examples.
build.openshift.io/source-secret-match-uri-1=https://gitlab.com/username/reponame.git
Result of oc version is as follows, matching the server version shown both in cli and on the about page in the OpenShift web console.
oc v3.10.9
kubernetes v1.10.0+b81c8f8
features: Basic-Auth
Server https://api.starter-us-east-1.openshift.com:443
openshift v3.10.9
kubernetes v1.10.0+b81c8f8
Related
When i try to execute the pipeline in gitlab ci, i get an error like fatal: repository 'http://practice-host.dfsystems.ru/gitlab-instance-8435ed1c/objective.git/' not found
enter image description here
My gitlab-runner deployed in kubernetes cluster
enter image description here
Deployed with helm with this yaml file:
enter image description here
I did ssh-keygen in gitlab-runner and added in gitlab ssh-keys, but still not working
This pipeline what i use now
enter image description here
If you have any idea, i will appreciate it <3
Here are some steps you can try to resolve the issue:
Verify the repository URL: Make sure that the URL you're using is correct and that you have access to the repository.
Check the GitLab instance: If you're using a self-hosted GitLab instance, check that it is accessible and reachable from the GitLab CI runner.
Check authentication: If the repository is private, make sure that the GitLab CI runner has the necessary access token or SSH key to clone the repository.
Check network connectivity: Ensure that the GitLab CI runner has network connectivity to the GitLab instance and the repository.
I've moved to linux (pop_os 21.04) on my desktop and I'm having some issues with docker.
When I'm trying to run docker-compose to pull an image from a private registry I'm getting:
ERROR: Head "https://my.registry/my-image/manifests/latest": no basic auth credentials
Of course before running this command I've ran:
docker login https://my.registry.com -u user -p pass
which returns
WARNING! Your password will be stored unencrypted in /home/user/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
And my config.json in my .docker folder show my credentials
{
"auths": {
"my.registry.com": {
"auth": "XXXXX"
}
}
}
To install docker I've followed instructions on their page https://docs.docker.com/engine/install/ubuntu/
And my version is:
Docker version 20.10.8, build 3967b7d
The same command ran on a macos system with Docker version 20.10.8 runs without any issues so I my password and all the urls are correct for sure.
Thanks for any help!
The login commands is
docker login my.registry.com
Without the https:// in front of the host. If you still have auth issues doing that:
if the registry uses an unknown TLS certificate, load that certificate on the host and restart the docker engine
if the registry is http instead of https, configure it as an insecure registry on /etc/docker/daemon.conf
if the login is successful, but the pull fails, verify your user has access to the specific repo on the registry
double check your password was correctly entered
check for a network proxy intercepting the request (the http_proxy variable)
I reinstalled the whole thing again as the docker page states, didn't work, so I uninstalled it and proceeded to install snap version, that didn't work neither and finally I removed it and went with simple apt-get install docker.io and it works like a charm! I don't know why it didn't work previously but I won't lose more sleep over it.
On Ubuntu 20.x, I observed that the credentials are stored in home/<username>/snap/docker/1125/.docker/config.json.
If older credentials are stored in $HOME/.docker/config.json, they are not used by docker pull. Verify if docker is indeed picking up the credentials from the right config.json location.
Using the newman nodeJS CLI to run a collection of postman test I get the following error:
error: unable to get local issuer certificate
It is run as part of a Teamcity CI build using the following command:
newman run https://www.getpostman.com/collections/<COLLECTION-ID-HERE>
It is run on windows and we have a corporate proxy server (ZScaler).
How to I get newman to work?
Just add --insecure in front of collectionID i.e :
newman run https://www.getpostman.com/collections/?apiKey="your-Postman-Api-Key" --insecure
Also When triggering the execution using a json file, Just add --insecure So your command shall be :
newman run .postman_collection.json --insecure
The issue is that newman cannot find (or does not know about) the self signed SSL certificate used by the proxy server that is configured in the windows certificate store. The easiest way to make newman (and actually any recent nodeJS app) aware of the certificate is to use an environment variable:
on windows:
SET NODE_EXTRA_CA_CERTS=c:\some-folder\certificate.cer
on linux:
export NODE_EXTRA_CA_CERTS=/c/some-folder/certificate.cer
You may also need to set the proxy server url itself with the HTTP_PROXY=http://example.com:1234 env varirable as well.
Alternatively the environment variables can be added to that teamcity builds runtime environment using the build parameters feature of Teamcity
Note this is for Node.js 7.3.0 and above (and the LTS versions 6.10.0 and 4.8.0)
I am trying to use the pre-packaged v3.0.3 war file for the jhipster-registry. I am launching it with these command-line properties in an attempt to point it to my Git repo for configuration info:
jhipster-registry-3.0.3.war --spring.profiles.active=prod,cust1 \
--spring.cloud.config.server.git.uri=http://myserver/url/MyConfig \
--spring.cloud.config.server.git.username=user \
--spring.cloud.config.server.git.password=pass
It starts, but I always get this error:
Your JWT secret key is not set up, you will not be able to log into the JHipster
I've tried many combinations of how to setup the Git repo. I'm using the sample application.yml file from https://github.com/jhipster/jhipster-registry-sample-config
Does the jhipster-registry itself not read any configuration files from Git?
If I want to configure the jhipster-registry properties, should I keep overriding things on the command-line, or put a yml file somewhere? It isn't clear to me the proper way to configure it when it is a pre-built war file and has embedded bootstrap/application yml files.
Is there a way to turn on debug logging so I can see what is going on?
This is because your JWT token isn't configured in your Git repository.
Have a look at our sample Git repository.
The Registry will send this token to all configured applications, and thus will be able to connect to them.
Otherwise, it shows a warning as it knows this will be an issue later.
Please note that this is a difference from the "classical" Eureka and Spring Cloud Config servers, which are not secured by default.
I have setup travis-ci to deploy to azure website, travis use dpl for deployment,
but I get unable to resolve host:
fatal: unable to access 'https://username:!password#https://test-ci.azurewebsites.net/.scm.azurewebsites.net:443/https://test-ci.azurewebsites.net/.git/': Couldn't resolve host 'https'
but the actual git url at azure portal is:
https://username#test-ci.scm.azurewebsites.net:443/test-ci.git
As my test, we only need to provide the site name to the .travis.yml file. It is enough (do not use web app url or git url as the value of site). The following is my deploy part in .travis.yml.
deploy:
provider: azure_web_apps
username: "jambor1" # If AZURE_WA_USERNAME isn't set
password: "***" # If AZURE_WA_PASSWORD isn't set
site: "travistestja" # If AZURE_WA_SITE isn't set
verbose: true
Here is the result:
when you are creating deployment credentials don't use '#' character or other special characters which will break the git repository path created by azure local git deployment.
Follow article https://learn.microsoft.com/en-us/azure/app-service-web/scripts/app-service-powershell-deploy-local-git where you will see that git is using username and password both for connecting to git repository, so if there are some difference in actual repository path in azure portal and in travis ci that is not the actual problem.