It was suggested that Microsoft/GitHub should have bought npm back in the day, instead of launching their own registry. Today is the day they’ve actually done it:
For the millions of developers who use the public npm registry every day, npm will always be available and always be free. Looking further ahead, we’ll integrate GitHub and npm to improve the security of the open source software supply chain, and enable you to trace a change from a GitHub pull request to the npm package version that fixed it.
When GitHub released its new product: GitHub Actions a whole new world opened for developers. Let’s dive right in and see what it brings for the Laravel community.
In How to set up PHP for use in a GitHub Action I’ve layed out how to use shivammathur/setup-php@v1 in GitHub Actions. This post goes very nicely along with it. Recommended read, even if you don’t write Laravel (like me).
I especially like the part where an extra MySQL service is spun up from within the workflow, and then used in the tests.
Recently I needed to test a branch of a forked GitHub repository inside a project. Instead of cloning the fork and symlinking the package locally, I installed the remote dependency directly into the project.
Leveraging GitHub Workflows’ Scheduled Events(read: cronjobs that run on GitHub) the folks at De Voorhoede let their static site automatically be rebuilt overnight. They do this because they have some external content, which doesn’t get committed into the repo, included on their site.
Static websites don’t update by themselves. In case of code changes (git push) and content changes (CMS publish event) a user triggers an update. But what if an external system (regularly) updates but can’t be configured to trigger an update? Enter cron jobs.
As their site is deployed onto Netlify, they let GitHub perform a curl request to Netlify’s Deploy Webhook, thus rebuilding and redeploying their site.
Their workflow file .github/workflows/nightly-build.yml is straightforward:
If your code/project always uses Pull Requests to add/fix stuff in your code (e.g. no direct commits on master), then Changelog Generator will come in handy. It’s a CLI tool (written in PHP) that automatically fetches all closed PRs and Issues between the targetted and the previously tagged release.
The snippet above will check all closed PRs and Issues that landed in between the 0.0.7 release and the one before (e.g. 0.0.6) of the repo jwage/changelog-generator.
- Total issues resolved: **1**
- Total pull requests resolved: **4**
- Total contributors: **3**
- [47: Upgrade Doctrine Coding Standards to 5.0](https://github.com/jwage/changelog-generator/pull/47) thanks to @jwage
- [43: Generate alternative (Setext, without #) Markdown format for headers](https://github.com/jwage/changelog-generator/pull/43) thanks to @Majkl578
- [38: Fix: Provide missing required php version in composer](https://github.com/jwage/changelog-generator/pull/38) thanks to @prisis
- [32: Upgrade PHPStan to 0.10](https://github.com/jwage/changelog-generator/pull/32) thanks to @jwage
Adding the --prepend --file=CHANGELOG.md options, will automatically prepend its output to CHANGELOG.md.
💡 In case you don’t always want to type the arguments you could define it as a custom composer command/script into your own project, or use a config file which is also supported.
Last week Christian Heilmann (codepo8) released a handy bookmarklet that lets on switch between the GitHub Pages URL of a repo hosted on GitHub and the repo contents itself. This afternoon I took the liberty of transforming it into a Chrome Extension, mainly as an exercise to myself.
The extension adds a small button which becomes active whenever you are visiting a *.github.com or *.github.io domain. Upon clicking the button you toggle between the two URLs.
To create this plugin I started out with the core of Christian’s script and decorated the required Chrome Extension stuff around it. A few notes on the latter though: