-
Updated
Sep 9, 2021 - Go
gitops
Here are 534 public repositories matching this topic...
-
Updated
Sep 21, 2021 - Go
We are using font-awesome V4 and should migrate to font-awesome V5 which comes with its own vue.js module: https://github.com/FortAwesome/vue-fontawesome
Migration includes removing old font-awesome V4 module and changing all existing icons to new vue.js tag.
This is blocked until #114 is merged which comes with first initial integration.
Summary
When creating docker images for Java applications in the current setup in Jenkins-X the application and all dependencies are all placed in one jar file, meaning it will be in one layer in the docker image.
This means that when new versions of the application are created the unchanged dependencies can't be reused.
It would be a great enhancement if the application code where p
Problem
Installation is not straightforward enough for some users.
Suggestion
Use goreleaser (with a homebrew option for mac users, etc). The resulting installation section of your readme could then look something like [this](https://github.com/scottrigby/example-dep-no-vendor/#example-installati
Describe the bug
There is a bug in podinfo chart which will not deploy service if you enabled canary, even though you enabled service via helm values.
https://github.com/fluxcd/flagger/blob/main/charts/podinfo/templates/service.yaml#L1
To Reproduce
If you set values like this, it will not deploy service.
service:
enabled: true # service will not be deployed if ca-
Updated
Sep 24, 2021 - Go
Using #1671 as an example we could add unit tests for the flux create secret git/helm/tls --export commands and validate the YAML output against golden file.
-
Updated
Sep 22, 2021 - Go
-
Updated
Sep 13, 2021 - Python
Summary
Spawned from argoproj/argo-rollouts#1525.
If using workloadRef, the plugin set image command does not work. We made it work for undo but not for set image.
Diagnostics
What version of Argo Rollouts are you running? v1.1.0-rc1
**Message
Describe the bug
Unnecessary text explaining the project migration history maximum display count when there is no migration history at all.
Steps or screenshots to reproduce the behavior
- Go to a project where none of its database contain migration history (e.g. a new project), and click "Migration History"
- It displays a label "For database having migration history, we list up
Describe your problem
When users run a mutator (e.g. set-annotations), the output doesn't tell them which files changed. The only way a user can figure out which files were affected is by looking through them manually or doing git status or however they might normally be notified of changes to files.
It would be nice if we were able to notify the user which files changed as a result
-
Updated
Sep 13, 2020 - Go
Authentication via Azure/aad-pod-identity for keyvault access could be a good feature to avoid use of clientId/ clientSecret in chart values. Don't you think ?
-
Updated
Jan 5, 2021 - Go
Expected behavior
When running the terraform step, all plan contents should be visible or there should be a scroll bar.
Actual behavior
A scrollbar never appears, and content clips off the bottom of the screen. If the page zoom is changed, content reflows and a scroll bar appears.
Information
- Ship version:
0.43.1 - Command line run:
ship init ./ship.yaml - Chrome v
valuesFromFile:
chartFileRef:
myScript: path/to/file.js
externalSourceRef:
defaultScript: https://raw.githubusercontent.com/cdenneen/example/master/script.jsresult in equivalent of:
helm install --set-file key=path/to/file.js
myScript: |
const { events, Job } = require("brigadier")
function run(e, project) {
console.log("this iAs discussed in slack.
In comparison to skaffold (another deployment tool), kapp only reports if the condition was met or not. I'd like to see more information about the stabilization process e.g:
Waiting for deployments to stabilize...
- production:deployment/demo: creating container service
- production:pod/demo-5cf5f768d4-x9xfr: creating container service
- production:deploy
What would you like to be added:
Why is this needed:
-
Updated
Sep 24, 2021
-
Updated
Feb 9, 2021 - HTML
kubectl schemahero get migrations command can output a long list of migrations, with potentially repeating names.
To find the right migration with a tool like grep, we need to look at the what schema files were changed to determine what the name of the migration would be.
It would be nice to list migrations sorted by timestamps or filter by migration state (open/approved/applied)
-
Updated
Sep 16, 2021 - Go
Improve this page
Add a description, image, and links to the gitops topic page so that developers can more easily learn about it.
Add this topic to your repo
To associate your repository with the gitops topic, visit your repo's landing page and select "manage topics."

Summary
Deployments can be paused and resumed (spec.paused). We could create a lua action for Deployments to modify this field.
Motivation
An action that allows this would remove the kubectl access currently needed for doing this.
Proposal
Implement the lua script for a pause and resume action for Deployments.