4 ms·

CI/CD should you perform tasks that you could execute on any machine, besides the deployment, which should work differently locally VS via CI service. But it sh

CI/CD should you perform tasks that you could execute on any machine, besides the deployment, which should work differently locally VS via CI service. But it should still be possible to deploy without CI, otherwise you set yourself up for being unable to deploy when you really need it.

kiloreux 5y ago
Yeah, but theory and practice are very different things. If CI always worked for me and my experience was great with it. I will not invest time to do independent CI for everything. Hence depending on Github Actions. Clearly not the best approach, but it's about being pragmatic also.
- chockchocschoir 5y ago
  What do you mean "independent CI"? You start with a `Makefile` with the commands for testing, building and so on, and CI is just calling those commands but on another instances, that likely gets triggered for each commit/tag/pull request/whatever. When you first setup CI, you don't actually just develop for the CI environment first, that's the second step after you know how to perform the same things locally. So not sure why there would be "independent CI for everything".
  - tyingq 5y ago
    It's easy enough to unintentionally box yourself into a hard 3rd party dependency. Like the github secrets store, conditional logic or triggers in the ci.yml files, pipeline driven semantic versioning, etc.
DogLover_ 5y ago
Github-actions is not created to encourage that though. It uses syntax that only works on Github. Look at their workflow-examples and you will see.
- chockchocschoir 5y ago
  Don't you define things in your repository first (usually via a `Makefile`) and then call those things in the CI environment? Or are you building things differently in the CI environment compared to the local environment? I mean, if you're working on a project that has tests, code coverage and binary builds setup, you usually have a `Makefile` or `package.json` or whatever to run your scripts, and your CI setup just calls those very same scripts but in their environment (sometimes with different arguments/environment variables). Not sure why it would be different for GitHub Actions. It's certainly how I use it day-to-day.
  - deckard1 5y ago
    no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Everything is hooked in to GitHub via their proprietary yaml config. > Not sure why it would be different for GitHub Actions. because vendor lock-in. GitHub doesn't want to make it easy for you to switch.
    - greggman3 5y ago
      You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?
      - tyingq 5y ago
        That's neat, though it is a 3rd party trying to replicate it. Gitlab's open source runner supports parsing the ci yml and running a job locally, presumably using the same code as the platform, like: gitlab-runner exec docker some-job-name Though they would both suffer on any dependencies on platform hosted environment vars, secrets managers, etc.
mhitza 5y ago
> But it should still be possible to deploy without CI, Solo? Yes. In a team? Less often just because you might have credentials stored in secrets that are not shared with the entire team for security reasons. In larger corps it's easier to wait it out that go through the trouble of escalating permission requests. But I do get your point. Personally for deployments I have Ansible playbooks that are invoked via straighforward calls which can be done locally.

kiloreux 5y ago

Yeah, but theory and practice are very different things. If CI always worked for me and my experience was great with it. I will not invest time to do independent CI for everything. Hence depending on Github Actions. Clearly not the best approach, but it's about being pragmatic also.

chockchocschoir 5y ago
What do you mean "independent CI"? You start with a `Makefile` with the commands for testing, building and so on, and CI is just calling those commands but on another instances, that likely gets triggered for each commit/tag/pull request/whatever. When you first setup CI, you don't actually just develop for the CI environment first, that's the second step after you know how to perform the same things locally. So not sure why there would be "independent CI for everything".
- tyingq 5y ago
  It's easy enough to unintentionally box yourself into a hard 3rd party dependency. Like the github secrets store, conditional logic or triggers in the ci.yml files, pipeline driven semantic versioning, etc.

DogLover_ 5y ago

Github-actions is not created to encourage that though. It uses syntax that only works on Github. Look at their workflow-examples and you will see.

chockchocschoir 5y ago
Don't you define things in your repository first (usually via a `Makefile`) and then call those things in the CI environment? Or are you building things differently in the CI environment compared to the local environment? I mean, if you're working on a project that has tests, code coverage and binary builds setup, you usually have a `Makefile` or `package.json` or whatever to run your scripts, and your CI setup just calls those very same scripts but in their environment (sometimes with different arguments/environment variables). Not sure why it would be different for GitHub Actions. It's certainly how I use it day-to-day.
- deckard1 5y ago
  no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Everything is hooked in to GitHub via their proprietary yaml config. > Not sure why it would be different for GitHub Actions. because vendor lock-in. GitHub doesn't want to make it easy for you to switch.
  - greggman3 5y ago
    You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?
    - tyingq 5y ago
      That's neat, though it is a 3rd party trying to replicate it. Gitlab's open source runner supports parsing the ci yml and running a job locally, presumably using the same code as the platform, like: gitlab-runner exec docker some-job-name Though they would both suffer on any dependencies on platform hosted environment vars, secrets managers, etc.

mhitza 5y ago

> But it should still be possible to deploy without CI, Solo? Yes. In a team? Less often just because you might have credentials stored in secrets that are not shared with the entire team for security reasons. In larger corps it's easier to wait it out that go through the trouble of escalating permission requests. But I do get your point. Personally for deployments I have Ansible playbooks that are invoked via straighforward calls which can be done locally.