microsoft never changes
GitHub Actions has a package manager, and it might be the worst
161–170 of 267 posts
Re: GitHub Actions has a package manager, and it might be the worst
#162Earlier quoted context omitted.
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
I was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
Yeah, but I have to set that up.
GitHub actions more or less just work for what most people need. If you have a complex setup, use a real CI/CD system.
Re: GitHub Actions has a package manager, and it might be the worst
#163Earlier quoted context omitted.
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
I was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
Thank you for the kind shout out! Always happy to see comments like this. If anyone is looking for a better GitHub or GitHub Actions experience, feel free to reach out anytime.
Re: GitHub Actions has a package manager, and it might be the worst
#164Earlier quoted context omitted.
I tried to use CircleCI and I gotta say, it is absolutely not better than GitHub Actions…
I have also used Travis. Ditto. Github Actions is actually one of the better CI options out there, even if on an absolute scale it is still pretty bad. As far as I can tell nobody has made a CI system that is actually good .
buildkite is leaps and bounds above the others. especially if you need to really tailor your workloads to the change diff (say in a monorepo), the dynamic pipeline support is superb.
really surprised there are no others though. dagger.io was in the space but the level of complexity is an order of magnitude higher
Re: GitHub Actions has a package manager, and it might be the worst
#165Earlier quoted context omitted.
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
I was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
Blacksmith.sh has been great for us. Massively sped up tests and a huge improvement for Docker builds over both Actions and Google Cloud Build.
Only downside is they never got back to us about their startup discount.
Re: GitHub Actions has a package manager, and it might be the worst
#166What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
It's not really that expensive. GitHub Enterprise is like $21/month/user while GitLab Ultimate was $100/month/user the last time GitLab published prices. These days GitLab Ultimate is "contact us for pricing" while the cheaper GitLab Premium is $29/month/user.
I guess Bitbucket is cheaper but you'll lose the savings in your employees bitching about Bitbucket to each other on Slack.
Re: GitHub Actions has a package manager, and it might be the worst
#167What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.
> Their entire ecosystem is basically held up with duct tape and gets very little investment.
That isn't gonna get better anytime soon.
"GitHub Will Prioritize Migrating to Azure Over Feature Development" [1]
[1] https://thenewstack.io/github-will-prioritize-migrating-to-a...
Re: GitHub Actions has a package manager, and it might be the worst
#168Earlier quoted context omitted.
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
I was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
What are Depot runners?
Re: GitHub Actions has a package manager, and it might be the worst
#169Earlier quoted context omitted.
The secret is held by the metadata server that the CI instance has access to Or: the deployment service knows the identity of the instance, so its secret is its private key Or, how PyPI does it: the deployment service coordinates with the trusted CI/CD service to learn the identity of the machine (like its IP address, or a trusted assertion of which repository it’s running on), so the secret is handled in however tha…
> The secret is held by the metadata server that the CI instance has access to But how does the metadata server know that the CI instance is allowed to access the secret? Especially when the CI/CD system is hosted at a 3rd. party. It needs to present some form of credentials. The CI system may also need permission or credentials for a private repository of packages or artifacts needed in the build process. For me, a…
Yeah I was confused about that bit too. AWS and GCP's metadata servers know which instances were deployed, so they presumably have some way of verifying the instance's identity out-of-band, such as being tagged by an internal job or machine identifier.
As for deploying from a trusted service without managing credentials, PyPI calls this "trusted publishing": https://docs.pypi.org/trusted-publishers/
From the docs:
1. Certain CI services (like GitHub Actions) are OIDC identity providers, meaning that they can issue short-lived credentials ("OIDC tokens") that a third party can strongly verify came from the CI service (as well as which user, repository, etc. actually executed);
2. Projects on PyPI can be configured to trust a particular configuration on a particular CI service, making that configuration an OIDC publisher for that project;
3. Release automation (like GitHub Actions) can submit an OIDC token to PyPI. The token will be matched against configurations trusted by different projects; if any projects trust the token's configuration, then PyPI will mint a short-lived API token for those projects and return it;
4. The short-lived API token behaves exactly like a normal project-scoped API token, except that it's only valid for 15 minutes from time of creation (enough time for the CI to use it to upload packages).
You have to add your github repository as a "trusted pulbisher" to your PyPI packages.
Honetsly the whole workflow bothers me -- how can PyPI be sure it's talking to github? what if an attacker could mess with PyPI's DNS? -- but it's how it's done.
Re: GitHub Actions has a package manager, and it might be the worst
#170While I hate defending GHA, the docs do include this: - Using the commit SHA of a released action version is the safest for stability and security. - If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author. So you can basically implement your own lock file, alth…
Using an SHA is an anti-pattern for me. Because by using one, you kind of modeled "I am getting this fixed/static thing"; when in reality, it is very far from that. I got bitten by it twice that I learned that you either have a lock file or you don't.