configuration-as-code-plugin
pipeline
configuration-as-code-plugin | pipeline | |
---|---|---|
12 | 51 | |
2,643 | 8,289 | |
0.4% | 0.3% | |
8.9 | 9.7 | |
5 days ago | 3 days ago | |
Java | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
configuration-as-code-plugin
-
Help! Confused about the relationship between Software Engineering and DevOps
First, developers could be taking care of maintaining the CI/CD tool.. As is (dev)ops will provide a running instance and everything from there is dev's responsibility, eg. Jenkins via https://plugins.jenkins.io/configuration-as-code/ .
- Jenkins CASC plugin
-
The only Jenkins Plugins you need
configuration-as-code https://plugins.jenkins.io/configuration-as-code/
- Fully scripted Jenkins server with terraform
-
Setting up a Jenkins instance with Configuration as Code (using yaml configuration)
Now we are going to use Configuration as Code plugin and some other plugins.
-
Why do y'all hate Jenkins? (What pipeline tools do you use?)
Looks like it does pretty much everything except install plugins ("We don't support installing plugins with JCasC" https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md)
- Separate .yamls for Jenkins Configuration-as-Code
-
My School DevOps Project [part 1] - Jenkins
--- jenkins: numExecutors: 1 systemMessage: "Hi, jenkins setup with jcasc" securityRealm: local: allowsSignup: false # prevents anonymous users from creating an account through the web interface users: - id: ${JENKINS_ADMIN_ID} password: ${JENKINS_ADMIN_PASSWORD} authorizationStrategy: globalMatrix: permissions: #- "View/Delete:authenticated" #- "View/Read:authenticated" #- "View/Configure:authenticated" #- "View/Create:authenticated" - "Job/Read:authenticated" - "Job/Build:authenticated" - "Job/Configure:authenticated" - "Job/Create:authenticated" - "Job/Delete:authenticated" - "Job/Discover:authenticated" - "Job/Move:authenticated" - "Job/Workspace:authenticated" - "Job/Cancel:authenticated" - "Run/Delete:authenticated" - "Run/Replay:authenticated" - "Run/Update:authenticated" - "Overall/Read:admin" - "Overall/Administer:admin" crumbIssuer: "standard" # Docker: https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos/docker clouds: - docker: name: "docker" dockerApi: dockerHost: uri: "unix:///var/run/docker.sock" templates: - labelString: "docker-agent" dockerTemplateBase: # TODO: pin sha256 or versions when using in production image: "jenkins/agent" remoteFs: "/home/jenkins/agent" connector: attach: user: "jenkins" instanceCapStr: "10" retentionStrategy: idleMinutes: 1 security: scriptApproval: approvedSignatures: - method java.lang.String indexOf int - method io.jenkins.plugins.casc.ConfigurationAsCode configure - staticMethod io.jenkins.plugins.casc.ConfigurationAsCode get tool: git: installations: - home: "git" name: "Default" jdk: installations: - home: "/opt/java/openjdk" name: "java" maven: installations: - name: "maven" properties: - installSource: installers: - maven: id: "3.6.2" jobs: - file: /var/jenkins_config/jobs/folders.groovy - file: /var/jenkins_config/jobs/jobs.groovy
-
Interesting Task
At my previous job the entirety of Jenkins was all in code. We would blow away our entire Jenkins instance and just copy/paste the config back into Jenkins and it would all be back. I believe that also had all of the configurations for the jobs as well. In that case, that could be ideal. If I remember correctly this was all done in Groovy and not using the Configuration as Code (YAML) plugin.
-
CMV: Jenkins shouldn't be anywhere near a robust, mature application environment
Most of the main plugins are configurable (here are some examples) and the rest you can configure via groovy. If there's good documentation, writing the groovy scripts is fairly easy too
pipeline
-
14 DevOps and SRE Tools for 2024: Your Ultimate Guide to Stay Ahead
Tekton
- GitHub Actions could be so much better
-
Distributed Traces for Testing with Tekton Pipelines and Tracetest
Tekton is an open-source framework for creating efficient CI/CD systems. This empowers developers to seamlessly construct, test, and deploy applications across various cloud environments and on-premise setups.
-
Practical Tips for Refactoring Release CI using GitHub Actions
Despite other alternatives like Circle CI, Travis CI, GitLab CI or even self-hosted options using open-source projects like Tekton or Argo Workflow, the reason for choosing GitHub Actions was straightforward: GitHub Actions, in conjunction with the GitHub ecosystem, offers a user-friendly experience and access to a rich software marketplace.
-
Wolfi: A community Linux OS designed for the container and cloud-native era
[2]: https://github.com/tektoncd/pipeline/issues/5507#issuecommen...
- Nu stiu ce sa fac, orice sfat e bine venit
-
What are some good self-hosted CI/CD tools where pipeline steps run in docker containers?
Drone, or Tekton, Argo Workflows if you’re on k8s
-
Is Jenkins still the king?
If you want a step up, I would recommend trying out Tekton Pipelines. It’s a very popular ci tool, and it runs on Kubernetes. Yes, this would involve setting up a Kubernetes cluster but please don’t run for the hills! You can setup a Kubernetes cluster and install Tekton on top of it with minimal setup using minikube (see here. This would be a great joint exercise as it will give you a bit of Kubernetes understanding alongside it, and the mechanisms of Tekton are a little trickier than GitHub actions imo. It’s all much the same though.
- Is there a way to run a one-off pod that would work as a command line tool?
-
K8s powered Git push deployments
I've recently found this quote by Kelsey Hightower:
"I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them."
Source: https://twitter.com/kelseyhightower/status/85193508753294540...
In the last few weeks, I've experimented a bit with Flux (https://fluxcd.io/), Tekton (https://tekton.dev/) and Cloud Native Buildpacks (https://buildpacks.io/) on how to provide K8s powered git push deployments without using a dedicated CI/CD server.
My project is still in early alpha stage and just a proof of concept :-) My vision is to expand it into an Open Source PaaS in the future.
Do you think the above quote is true? What does an open source PaaS need to be like in order to be accepted by software developers?
Some other projects have been discontinued in the past (like Flynn or Deis) or were created before the Kubernetes era.
Is it the right direction to provide a Heroku like solution based on K8s or is it better to provide an Open Source Infrastructure as Code library with building blocks to avoid everything from scratch?
What are some alternatives?
jenkins-bootstrap-shared - Jenkins as immutable infrastructure made easy. A repository of shared scripts meant to be used as a git submodule. Packing Jenkins, plugins, and scripts into immutable packages and images.
dagger - Application Delivery as Code that Runs Anywhere
job-dsl-gradle-example - An example Job DSL project that uses Gradle for building and testing.
argo-cd - Declarative Continuous Deployment for Kubernetes
artifact-manager-s3-plugin - Artifact manager implementation for Amazon S3
kubevela - The Modern Application Platform.
warnings-ng-plugin - Jenkins Warnings Plugin - Next Generation
tekton-argocd-poc - This a PoC using Tekton (for CI) and ArgoCD (CD). It uses a local k8s cluster (K3D)
Design Patterns - Design patterns implemented in Java
NUKE - 🏗 The AKEless Build System for C#/.NET
docker - Docker official jenkins repo
skaffold - Easy and Repeatable Kubernetes Development