Only thing I don't like about GitHub Actions so far is the YAML structure. e.g. name: master-pull-request on: pull_request: branches: - master jobs: test: name: run tests runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v1 - name: Run gradle test run: | ./gradlew test I much prefer Drone CI's YAML: kind: pipeline name: default steps: - name: run tests image: openjdk:8-jdk-slim # Docker images! commands: - ./grad…
GitHub's format is like Drone's "multiple pipelines" feature in a single document instead of separate ones. Drone uses multiple documents that each define a different set of steps while GitHub does that in a single document with separate jobs.
It's just an issue of preference, I suppose, but I prefer GitHub's way of doing things. I find it easier to read and understand.
I am with you on this. It seems to be a new trend: “show users how to do a hello world” which was disregarded in the past... but somehow that turned into “instead of providing real documentation” rather than “in addition to.” It’s not just GitHub. There’s a language I (and the rest of HN) love that has adopted “story format” for documentation but is missing real, hard technical documentation apart from method-level c…
Someone please tell the Google Cloud Platform teams this. So many hello world examples which reek of, "I was told to write documentation but I really hate writing documentation". I mean this in good faith, I think writing documentation for a product you don't actually use is a miserable experience and I hope they can find a better balance... Writing documentation also seems to be a task you kick out to your junior de…
GCP documentation is the worst I have come across so far. The GCP documentation seems to have multiple personalities. It is as if the different parts of the documentation were written by different teams in different corners of the company.
I have to often disregard the documentation and get into the gcloud (their Python-based CLI and API) to understand what the heck is going on and their CLI/API code is no good either. Layers and layers of abstraction in their code only to make some REST API calls. The amount of over-engineering and abstraction that is present in their Python code would put even Java SimpleBeanFactoryAwareAspectInstanceFactory developers to shame.
Maybe it's changed in the last month or two, but last time I looked at GitHub actions I couldn't find a single example of "Build docker container and push to GitHub Packages".
There are a lot of cool examples demo'ing some nifty stuff, but I'd like to see a lot of very basic examples first. The sort of thing anyone could/would copy into their project and use, then later learn how to make it fancy.
Product Manager for GitHub Actions here. Sorry that this was difficult for you - we're continuing to work on our documentation for both GitHub Actions and Github Packages (and how to use them together) and we'll make sure that we improve this. For my Java project, I set up GitHub Packages as a server in my settings.xml, and then use: mvn deploy -Dgithub.username=${{github.actor}} -Dgithub.password=${{github.token}} -…
I've converted our teams CI/CD to use github actions (from mostly running on AWS) at a large company since early in the beta, but we have also run into a lot of issues. Where can I report these issues and get a real answer? I don't mind getting told that a certain feature is on the backburner, I just want to know that someone has considered it.
The best place to report issues or request features is https://github.community/. The Product and Support teams both visit that regularly.
If there's one documentation that I hate with my gut, that is GCP documentation. Like wtf is going on there. Just to give you an example of how horrible it is, just check their Vision documentation: https://cloud.google.com/vision/docs/ They have quick starts, tutorials and how-to-guides. How are even those things conceptually different at all?. And their reference is just a list of their methods like if I knew out o…
It's possible that I'm jaded by non-existing documentation, but skimming over the docs in your link, this actually looks like an example of good documentation* The API reference in particular you pointed to has a top-level description + linkable reference to each individual method / resource along with brief description. AND, for older versions, as well as a description of "objects" used in the API. I guess it would…
In this case, google cloud vision, it seems like the docs are fine. It’s the platform that’s confusing because it requires too much ceremony to get started.
I would hesitate to build on anything that relies on GitHub native tooling. GitHub support is absolutely the worst. Their tools fail in weird ways at times, and without support you will be stuck. For personal/non production apps, fine. But beware of using it as a core part of your infrastructure.
Thanks for the warning, are there any good tools that integrate with pull request checks that can be self hosted? We self host nearly everything at work except for github. (And it's VERY difficult for me to get anything that costs money approved regardless of price)
Product Manager for GitHub Actions here. You can self-host the GitHub Actions runners. This means that you can run CI/CD workflows on your own hardware, while your source code is hosted on github.com itself. https://help.github.com/en/actions/automating-your-workflow-...
I read an article[0] on HN[1] recently — it talks about the different types of documentation. To quote it directly: "Documentation needs to include and be structured around its four different functions: tutorials, how-to guides, explanation and technical reference. Each of them requires a distinct mode of writing. People working with software need these four different kinds of documentation at different times, in dif…
What is the difference between a tutorial and a how-to guide?
Think of how tos as recipes for different scenarios
I have spent the last two days fighting with these new Github tools. I've been trying to do a simple Hello-World Maven app, built on Github Actions and deployed to Github Packages. It does not work. Github documentation is a disaster. They leave out critical parts. They don't provide examples. Everything they write is terse, confusing, and incomplete. They have short little articles on how to do things, and for each…
Sorry you've been fighting this. We're actively working on the documentation as well as improving the setup workflows for Actions which should alleviate lots of this pain. Those one line snippets are likely going to be taken down, most systems are too complicated for those to work. It looks nice for a couple package systems but that Maven one is obviously flawed. I'd be happy to help you dig through whatever you're t…
Hi there! Could I also ask for some documentation on the proper way to get a Windows CI system that has popular software (like Clang, MSYS2, etc.)? I know you can install these via NuGet, but it has a habit of failing a ton randomly (503 server error or other random stuff) and having to install each tool on every build slows things down a ton. I assume there must exist images that already have these? (This has been a mystery for me to figure out. I don't know if it's relevant, but I'm not a Docker user.)
I have spent the last two days fighting with these new Github tools. I've been trying to do a simple Hello-World Maven app, built on Github Actions and deployed to Github Packages. It does not work. Github documentation is a disaster. They leave out critical parts. They don't provide examples. Everything they write is terse, confusing, and incomplete. They have short little articles on how to do things, and for each…
> Github documentation is a disaster. They leave out critical parts. They don't provide examples. Everything they write is terse, confusing, and incomplete. Agreed. A lot of times they seemed to use the ole "make a blog post about X and we'll call it documentation" strategy that a lot of others seem to be employing as well. The net result is useless documentation that is often outdated by the time a product is live.…
There’s a really stupid simple partial fix for this but it seems to be non obvious to a lot of people.
And that’s to watch a coworker who hasn’t used it before try to follow your docs. Try again, and then pick another coworker. By then it should be good enough for the majority to follow, and you take the rest of the questions as they come. Put the first draft out and you’ll be swamped with complaints.