- Endpoint to onboard a repo with automatic analysis
curl -X POST "https://sonarcloud.io/api/alm_integration/provision_projects" \ -H "Authorization: Bearer <TOKEN>" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "installationKeys={ORG_NAME}/{REPO_NAME}|{REPO_ID}" \ --data-urlencode "organization={ORG_NAME}"
- How to find github
repo_id
inchrome
- Click on More Tools
Employing the single-container pattern means just putting your application into a container. It's how you usually start your container journey. But it's important to keep in mind that this pattern is all about simplicity, meaning that the container must have only one responsibility. That means it's an anti-pattern to have a web server and a log processor in the same container.
Containers are commonly used for web apps, where you expose an HTTP endpoint. But they can be used for many different things.
In Docker, you have the ability to change the behavior of a container at runtime, thanks to the CMD and ENTRYPOINT instructions. So I'm not limited to using containers for HTTP services. I can also use them for any bash script that accepts some parameters at runtime.
By letting containers change behavior at runtime, you can create a base container that can be reused in different contexts. So you'd use the single-container pattern to expose
Imagine that you are versioning your sourcecode in git and building your code via maven. You need to make releases before deploying to production regularly. What should be the strategy we need to follow for releasing?
I've used maven-release-plugin for years to make releases. It worked perfectly with maven and svn, but we started to face problems when we migrated our code to git and to make releases on git.
After checking the literature, we decided to use JGit-Flow which is a maven plugin based on and is a replacement for the maven-release-plugin enabling support for git-flow style releases via maven.
I do not want to explain the details much because there are many great posts explaining all.
name: my-app-chart | |
version: 0.0.1 # Use Jenkinsfile for versioning | |
description: My App | |
keywords: | |
- app | |
maintainers: | |
- name: Jeroen Rosenberg | |
email: jeroen.rosenberg@gmail.com | |
engine: gotpl |
- Prior to version 1.11, Kubernetes used iptables NAT and the conntrack kernel module to track connections. To list all the connections currently being tracked, use the conntrack command:
- To list conntrack-tracked connections to a particular destination address, use the -d flag:
conntrack -L -d 10.32.0.1
- It's possible your connection tracking table is full and new connections are being dropped. If that's the case you may see messages like the following in your system logs:
- Create service account for user Alice
kubectl create sa alice
- Get related secret
secret=$(kubectl get sa alice -o json | jq -r .secrets[].name)
- Get ca.crt from secret (using OSX base64 with -D flag for decode)