Today Weaveworks announces a partnership with Intuit to create Argo Flux, a major open source project to drive GitOps application delivery for Kubernetes via an industry-wide community. Argo Flux combines the Argo CD project led by Intuit with the Flux CD project driven by Weaveworks.
super, waiting to see what they will have in the end
yeh - i’m getting a bit annoyed at the “we’re going to work on a thing” announcements
it’s becoming common
pull_request_rules: - name: auto-approve dependabot pull requests conditions: - author~=dependabot\[bot\]\|dependabot-preview\[bot\] - status-success=continuous-integration/appveyor/pr - status-success=continuous-integration/travis-ci/pr actions: review: type: APPROVE - name: auto-merge dependabot pull requests conditions: - author~=dependabot\[bot\]\|dependabot-preview\[bot\] - "#approved-reviews-by>=1" actions: merge: method: merge
certainly some overlap in what it does and github actions
No, but have somethings bookmarked to achieve the same thing with actions
Want to use actions :-)
Anyone have trouble finding the line with abstraction in Jenkins pipeline libs? I forked someone’s codebase at worked and played around with it. While it works, you have to drudge through documentation that’s formatted for github which is terrible compared to typical code documentation. You (or someone) end up trying to write reusable code but end up with a bunch of one-offs (multiple docker run stages). You’re forced to figure out all the variables that are set by hoping the person that wrote the documentation didn’t miss anything, so you end up looking through the code to verify. I think with my current project I’m going to leave most of the logic in our pipeline.yaml and let it tell the story of how our build works instead of the Jenkinsfile. I’m pretty sure I could write a book about it or find someone else that’s already gone through my grief. Just venting a bit too
Join us if free!
My motivation is we are starting a Jenkins project next week.
Thanks for the invite. Just registered.
That is great @Erik Osterman Jenkins is a swiss knife in the CI/CD world and it must be in SweetOps team’s backpack
haha, yea, it was and then it wasn’t it’s a love/hate relationship.
but seeing as how many companies still use it, I totally agree!
yea, but in most cases Jenkins is very redundant for usual operations - build couple images and push them to registry. For this purpose I choose “free” CI tools linke Drone, GitlabCI and etc. Or if we need self managed solution - GitLab CI
But if we need some advanced logic in or pipelines - Jenkins is that we need
Updated our alpine packages repo: https://github.com/cloudposse/packages/tree/master/.github/workflows
Cloud Posse installer and distribution of native apps, binaries and alpine packages - cloudposse/packages
- auto update packages (open a PR every night)
- auto label PR with each package updated (great for mono repos)
- auto clean up branches on merge
- auto assign PR for review
(all github actions)
Need a suggestion : We are hosting a React website on S3, deployed through Jenkins. We have a story to set the site’s environment variables at deployment time (e.g. APIs URL, Vertex Cloud Auth Server , Redirection URL, etc.) but wanted to ping you guys to see if you are doing something like this today
we’re using AWS SSM Parameters – we use a multi-account strategy so each environment: DEV, TEST, PROD is a separate account with their own SSM parameters (keys are the same, values are different). My build process pulls the run time environment variables from SSM param store. for local dev, the team uses a
.env file with default values.
Yea, so a long these lines you’re basically going to want to do text replacement on the generated react site
envsubst are what we would use
whatever you upload to S3 needs to be static and cannot use envs
so you’ll need to use the envs as part of the CD process
We use the webpack plugin to setup env variables during build stage on CI (https://www.npmjs.com/package/dotenv-webpack) and as described above you can pull variables from AWS SSM or just put your variables to
.env.production and keep in git, cause these variables should not contain sensitive data
A simple webpack plugin to support dotenv.
That sounds even better
A GitHub action to create a pull request for changes to your repository in the actions workspace. - peter-evans/create-pull-request
Very cool GitHub action