3 ms·

One advantage for GitHub is that you’re less likely to migrate to another Git forge.

by Hackbraten 2y ago

misnome 2y ago
Which of any the alternatives don’t have their own unique solution?
- Hackbraten 2y ago
  The question was "GitHub CI YAML vs. pipeline.sh", not "GitHub CI YAML vs. other forge’s YAML." What I’m trying to say is that if you keep your build logic in `pipeline.sh` (and use GitHub CI only for calling into it), then you’re going to have an easier time migrating to another forge’s CI than in the alternative scenario, i.e. if your build logic is coded in GitHub CI YAML.
  - misnome 2y ago
    Obviously. But then you still have caching, passing data/artifacts between stages, workflow logic (like skipping steps if unnecessary), running on multiple platforms, and exposing test results/coverage to the system you are running in. Written properly, actually building the software is the least of what the CI is doing. If your build is simple enough that you don’t need any of that - great. But pretending that the big CI systems never do anything except lock you in is a trifle simplistic.
prmoustache 2y ago
Pipelines are usually just a list of sequential steps. I have been working with a lot of different CI/CD tools and they are among the easiest thing to move from one to another.
- Hackbraten 2y ago
  One example: for my personal Python projects, I use two GitHub actions named `pypa/gh-action-pypi-publish` [0] and `sigstore/gh-action-sigstore-python` [1] to sign my wheels, publish my wheels to PyPI, and have PyPI attest (and publicly display via check mark [2]) that the uploaded package is tied to my GitHub identity. How would I even begin migrating this to another forge? And that’s just a small part of the pipeline. [0]: https://github.com/marketplace/actions/pypi-publish https://github.com/marketplace/actions/pypi-publish [1]: https://github.com/marketplace/actions/gh-action-sigstore-python https://github.com/marketplace/actions/gh-action-sigstore-py... [2]: https://pypi.org/project/itchcraft/ https://pypi.org/project/itchcraft/
  - woodruffw 2y ago
    This is only a small part, but FWIW: you don’t need gh-action-sigstore-python to do the signing; gh-action-pypi-publish will do it automatically for you now. (Source: I maintain the former and contributed the attestations change to the latter.)
  - prmoustache 2y ago
    sigstore is not a github action specific tool, you can use the python client with any CI/CD tool runner. You can attest with py_pi attestations and publish with twine. When migrating the steps don't have to use the same syntax and tools, but for each step you can identify the desired outcome and create it without actions from the gh marketplace on a different CI/CD. More importantly, you consciously decided to make your pipeline not portable by using gh actions from the marketplace. This is not a requirement nor inevitable.

One advantage for GitHub is that you’re less likely to migrate to another Git forge.

misnome 2y ago

Which of any the alternatives don’t have their own unique solution?

Hackbraten 2y ago
The question was "GitHub CI YAML vs. pipeline.sh", not "GitHub CI YAML vs. other forge’s YAML." What I’m trying to say is that if you keep your build logic in `pipeline.sh` (and use GitHub CI only for calling into it), then you’re going to have an easier time migrating to another forge’s CI than in the alternative scenario, i.e. if your build logic is coded in GitHub CI YAML.
- misnome 2y ago
  Obviously. But then you still have caching, passing data/artifacts between stages, workflow logic (like skipping steps if unnecessary), running on multiple platforms, and exposing test results/coverage to the system you are running in. Written properly, actually building the software is the least of what the CI is doing. If your build is simple enough that you don’t need any of that - great. But pretending that the big CI systems never do anything except lock you in is a trifle simplistic.

prmoustache 2y ago

Pipelines are usually just a list of sequential steps. I have been working with a lot of different CI/CD tools and they are among the easiest thing to move from one to another.

Hackbraten 2y ago
One example: for my personal Python projects, I use two GitHub actions named `pypa/gh-action-pypi-publish` [0] and `sigstore/gh-action-sigstore-python` [1] to sign my wheels, publish my wheels to PyPI, and have PyPI attest (and publicly display via check mark [2]) that the uploaded package is tied to my GitHub identity. How would I even begin migrating this to another forge? And that’s just a small part of the pipeline. [0]: https://github.com/marketplace/actions/pypi-publish https://github.com/marketplace/actions/pypi-publish [1]: https://github.com/marketplace/actions/gh-action-sigstore-python https://github.com/marketplace/actions/gh-action-sigstore-py... [2]: https://pypi.org/project/itchcraft/ https://pypi.org/project/itchcraft/
- woodruffw 2y ago
  This is only a small part, but FWIW: you don’t need gh-action-sigstore-python to do the signing; gh-action-pypi-publish will do it automatically for you now. (Source: I maintain the former and contributed the attestations change to the latter.)
- prmoustache 2y ago
  sigstore is not a github action specific tool, you can use the python client with any CI/CD tool runner. You can attest with py_pi attestations and publish with twine. When migrating the steps don't have to use the same syntax and tools, but for each step you can identify the desired outcome and create it without actions from the gh marketplace on a different CI/CD. More importantly, you consciously decided to make your pipeline not portable by using gh actions from the marketplace. This is not a requirement nor inevitable.