4 ms·

> You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript

by ahepp 3y ago

> You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script. It took me an embarrassingly long time to learn that you don't need to use their little action plugins for everything. Once I figured that out, and figured out how to run CI in a container specified by the repo, I was actually quite happy to transition my CI away from Jenkins (which was always pretty rough, but I knew I could keep the builds running locally that way). I guess the real proof will be if I'm able to ever leave GitHub, but I feel pretty good about the amount of lock-in vs the benefits of the service.

tuukkah 3y ago
> to run CI in a container specified by the repo Would you happen to have an example YAML at hand?
- ahepp 3y ago
  Here's one: https://github.com/ahepp/resume/blob/d7778b1339271cbd78126345f900698f100e5c84/.github/workflows/main.yml https://github.com/ahepp/resume/blob/d7778b1339271cbd7812634... It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile. So when I'm developing on any Linux system, I can run $ docker build .ci/Dockerfile -t my-container $ docker run --rm -it -v $(pwd):/project -w /project my-container And have a shell with my LaTeX environment all ready to go. I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for. I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced: https://github.com/ahepp/resume/commit/a144ee06b868ae867b2875b422bc4731be600bb9 https://github.com/ahepp/resume/commit/a144ee06b868ae867b287... For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.
  - tuukkah 3y ago
    Thank you for sharing! This shows nicely how you can keep the GitHub YAML at minimum by referring to an action (in this case devcontainers/ci) which configures itself based on the content of the repo.

by ahepp 3y ago

tuukkah 3y ago

> to run CI in a container specified by the repo Would you happen to have an example YAML at hand?

ahepp 3y ago
Here's one: https://github.com/ahepp/resume/blob/d7778b1339271cbd78126345f900698f100e5c84/.github/workflows/main.yml https://github.com/ahepp/resume/blob/d7778b1339271cbd7812634... It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile. So when I'm developing on any Linux system, I can run $ docker build .ci/Dockerfile -t my-container $ docker run --rm -it -v $(pwd):/project -w /project my-container And have a shell with my LaTeX environment all ready to go. I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for. I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced: https://github.com/ahepp/resume/commit/a144ee06b868ae867b2875b422bc4731be600bb9 https://github.com/ahepp/resume/commit/a144ee06b868ae867b287... For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.
- tuukkah 3y ago
  Thank you for sharing! This shows nicely how you can keep the GitHub YAML at minimum by referring to an action (in this case devcontainers/ci) which configures itself based on the content of the repo.