Typos
This commit is contained in:
parent
fe2afc94af
commit
3429fd6318
1 changed files with 32 additions and 32 deletions
|
@ -23,7 +23,7 @@ Github has
|
||||||
[too often taken the wrong side](https://www.bleepingcomputer.com/news/software/github-threatens-to-ban-users-who-bypass-youtube-dl-takedown/)
|
[too often taken the wrong side](https://www.bleepingcomputer.com/news/software/github-threatens-to-ban-users-who-bypass-youtube-dl-takedown/)
|
||||||
in DMCA disputes since it's been acquired by Microsoft. The
|
in DMCA disputes since it's been acquired by Microsoft. The
|
||||||
[CEO of Github has in the meantime tried to redeem himself](https://devrant.com/rants/3366288/seems-like-even-githubs-ceo-has-now-chimed-in-on-the-youtube-dl-takedown-https-t),
|
[CEO of Github has in the meantime tried to redeem himself](https://devrant.com/rants/3366288/seems-like-even-githubs-ceo-has-now-chimed-in-on-the-youtube-dl-takedown-https-t),
|
||||||
but the damage in the eyes of many developers, myself included, was done, all in spite of the friendly olive branch
|
but the damage in the eyes of many developers, myself included, was done, despite the friendly olive branch
|
||||||
to the community handed over IRC. Most of all, that doesn't change the fact that Github has
|
to the community handed over IRC. Most of all, that doesn't change the fact that Github has
|
||||||
[taken down more than 2000 other repos](https://github.com/github/dmca/tree/master/2020) in 2020 alone,
|
[taken down more than 2000 other repos](https://github.com/github/dmca/tree/master/2020) in 2020 alone,
|
||||||
often without any appeal or legal support - the CEO bowed down in the case of `youtube-dl` only because of the massive
|
often without any appeal or legal support - the CEO bowed down in the case of `youtube-dl` only because of the massive
|
||||||
|
@ -31,13 +31,13 @@ publicity that the takedown attracted. Moreover, Github has yet to overcome its
|
||||||
it advertises itself like the home for open-source software, but its own source code is not open-source, so you can't
|
it advertises itself like the home for open-source software, but its own source code is not open-source, so you can't
|
||||||
spin up your own instance on your own server. There's also increasing evidence in support of my initial suspicion that
|
spin up your own instance on your own server. There's also increasing evidence in support of my initial suspicion that
|
||||||
the Github acquisition was nothing but another
|
the Github acquisition was nothing but another
|
||||||
old-school [Microsoft triple-E operation](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish). When you want
|
old-school [Microsoft triple-E operation](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish). Nowadays, when
|
||||||
to clone a Github repo you won't be prompted anymore with the HTTPS/SSH link by default, you'll be prompted with the
|
you want to clone a Github repo you won't be prompted anymore with the HTTPS/SSH link by default. You'll be prompted
|
||||||
Github CLI command, which extends the standard `git` command, but it introduces a couple of naming inconsistencies here
|
with the Github CLI command, which extends the standard `git` command, but it introduces a couple of naming
|
||||||
and there. They could have contributed to improve the `git` tool for everyone's benefit instead of providing their new
|
inconsistencies here and there. They could have contributed to improving the `git` tool for everyone's benefit instead
|
||||||
tool as the new default, but they have opted not to do so. I'm old enough to have seen quite a few of these examples in
|
of providing their new tool as the new default, but they have opted not to do so. I'm old enough to have seen quite a
|
||||||
the past, and it never ended well for the _extended_ party. As a consequence of these actions, I
|
few of these examples in the past, and it never ended well for the _extended_ party. As a consequence of these actions,
|
||||||
have [moved the Platypush repos to a self-hosted Gitlab instance](https://git.platypush.tech/platypush) - which comes
|
I have [moved the Platypush repos to a self-hosted Gitlab instance](https://git.platypush.tech/platypush) - which comes
|
||||||
with much more freedom, but also no more Github actions.
|
with much more freedom, but also no more Github actions.
|
||||||
|
|
||||||
And, after the announcement of the
|
And, after the announcement of the
|
||||||
|
@ -75,17 +75,17 @@ In this article we'll how to use Platypush to set up a pipeline that:
|
||||||
|
|
||||||
- Runs a suite of tests.
|
- Runs a suite of tests.
|
||||||
|
|
||||||
- If the tests succeed, then it proceeds with packaging the new version of the codebase - in my case, I run the
|
- If the tests succeed, it proceeds with packaging the new version of the codebase - in my case, I run the
|
||||||
automation to automatically create the new [`platypush-git`](https://aur.archlinux.org/packages/platypush-git) package
|
automation to automatically create the new [`platypush-git`](https://aur.archlinux.org/packages/platypush-git) package
|
||||||
for Arch Linux on new pushes, and the new [`platypush`](https://aur.archlinux.org/packages/platypush) Arch package and
|
for Arch Linux on new pushes, and the new [`platypush`](https://aur.archlinux.org/packages/platypush) Arch package as
|
||||||
the [`pip` package](https://pypi.org/project/platypush/) on new tags.
|
well as the [`pip` package](https://pypi.org/project/platypush/) on new tags.
|
||||||
|
|
||||||
- If the tests fail, it sends a notification (over
|
- If the tests fail, it sends a notification (over
|
||||||
[email](https://docs.platypush.tech/en/latest/platypush/plugins/mail.smtp.html),
|
[email](https://docs.platypush.tech/en/latest/platypush/plugins/mail.smtp.html),
|
||||||
[Telegram](https://docs.platypush.tech/en/latest/platypush/plugins/chat.telegram.html),
|
[Telegram](https://docs.platypush.tech/en/latest/platypush/plugins/chat.telegram.html),
|
||||||
[Pushbullet](https://docs.platypush.tech/en/latest/platypush/plugins/pushbullet.html) or
|
[Pushbullet](https://docs.platypush.tech/en/latest/platypush/plugins/pushbullet.html) or
|
||||||
[whichever plugin supported by Platypush](https://docs.platypush.tech/en/latest/)). Also send a notification if the
|
[whichever plugin supported by Platypush](https://docs.platypush.tech/en/latest/)). It also sends a notification if
|
||||||
latest run of tests has succeeded and the previous one was failing.
|
the latest run of tests has succeeded and the previous one was failing.
|
||||||
|
|
||||||
Note: since I have moved my projects to a self-hosted Gitlab server, I could have also relied on the native Gitlab CI/CD
|
Note: since I have moved my projects to a self-hosted Gitlab server, I could have also relied on the native Gitlab CI/CD
|
||||||
pipelines, but I have eventually opted not to do so for two reasons:
|
pipelines, but I have eventually opted not to do so for two reasons:
|
||||||
|
@ -152,7 +152,7 @@ backend.http:
|
||||||
|
|
||||||
Gitlab webhooks are a very simple and powerful way of triggering things when something happens on a Gitlab repo. All
|
Gitlab webhooks are a very simple and powerful way of triggering things when something happens on a Gitlab repo. All
|
||||||
you have to do is setting up a URL that should be called upon a repository event (push, tag, new issue, merge request
|
you have to do is setting up a URL that should be called upon a repository event (push, tag, new issue, merge request
|
||||||
etc.), and set up an automation on the endpoint that reacts to the event.
|
etc.), and set up a piece of automation on the endpoint that reacts to the event.
|
||||||
|
|
||||||
The only requirement for this mechanism to work is that the endpoint must be reachable from the Gitlab host - it means
|
The only requirement for this mechanism to work is that the endpoint must be reachable from the Gitlab host - it means
|
||||||
that the host running the Platypush web service must either be publicly accessible, on the same network or VPN as the
|
that the host running the Platypush web service must either be publicly accessible, on the same network or VPN as the
|
||||||
|
@ -388,7 +388,7 @@ And here you go - you should now be ready to create your automation routines on
|
||||||
Even though I have moved the Platypush repos to a self-hosted domain, I still keep a mirror of them on Github. That's
|
Even though I have moved the Platypush repos to a self-hosted domain, I still keep a mirror of them on Github. That's
|
||||||
because lots of people have already cloned the repos over the years and may lose updates if they haven't seen the
|
because lots of people have already cloned the repos over the years and may lose updates if they haven't seen the
|
||||||
announcement about the transfer. Also, registering to a new domain is often a barrier for users who want to create
|
announcement about the transfer. Also, registering to a new domain is often a barrier for users who want to create
|
||||||
issues. So, even though me and Github are no longer friends, I still need a way to easily mirror each new commit on my
|
issues. So, even though I and Github are no longer friends, I still need a way to easily mirror each new commit on my
|
||||||
domain to Github - but you might as well have another compelling case for backing up/mirroring your repos. The way
|
domain to Github - but you might as well have another compelling case for backing up/mirroring your repos. The way
|
||||||
I'm currently achieving this is by cloning the main instance of the repo on the machine that runs the Platypush service:
|
I'm currently achieving this is by cloning the main instance of the repo on the machine that runs the Platypush service:
|
||||||
|
|
||||||
|
@ -511,10 +511,10 @@ def on_repo_push(event, **_):
|
||||||
|
|
||||||
Upon push event, the latest version of the repo will be cloned under `/tmp/repo` and the suite of tests will be run.
|
Upon push event, the latest version of the repo will be cloned under `/tmp/repo` and the suite of tests will be run.
|
||||||
The output of each session will be stored under `/var/log/tests` in a file formatted like
|
The output of each session will be stored under `/var/log/tests` in a file formatted like
|
||||||
`<ISO timestamp>_<PASSED|FAILED>.log`. To make things even more robust, you can create a new virtual environment under
|
`<ISO_timestamp>_<PASSED|FAILED>.log`. To make things even more robust, you can create a new virtual environment under
|
||||||
the temporary directory, install your repo with all of its dependency in the new virtual environment and run the tests
|
the temporary directory, install your repo with all of its dependency in the new virtual environment and run the tests
|
||||||
from there, or spin a Docker instance with the required configuration, to make sure that the tests would also pass on a
|
from there, or spin a Docker instance with the required configuration, to make sure that the tests would also pass on a
|
||||||
fresh installation and prevent the _"but if works on my box"_ issue.
|
fresh installation and prevent the _"but it works on my box"_ issue.
|
||||||
|
|
||||||
## Serve the test results over HTTP
|
## Serve the test results over HTTP
|
||||||
|
|
||||||
|
@ -526,7 +526,7 @@ $ cd /var/log/tests
|
||||||
$ python -m http.server 8000
|
$ python -m http.server 8000
|
||||||
```
|
```
|
||||||
|
|
||||||
The logs will be served on `http://host:8000`. You can also serve the directory through a proper web server like nginx
|
The logs will be served on `http://host:8000`. You can also serve the directory through a proper web server like Nginx
|
||||||
or Apache.
|
or Apache.
|
||||||
|
|
||||||
![CI logs over HTTP](../img/ci-1.png)
|
![CI logs over HTTP](../img/ci-1.png)
|
||||||
|
@ -563,12 +563,12 @@ relying on any cloud runner.
|
||||||
|
|
||||||
## Automatic build and test notifications
|
## Automatic build and test notifications
|
||||||
|
|
||||||
Another useful feature of the popular cloud services is the ability to send notification when a build status changes.
|
Another useful feature of most of the popular cloud services is the ability to send notifications when a build status
|
||||||
This is quite easy to set up with Platypush, as the application provides several plugins for messaging. Let's look at
|
changes. This is quite easy to set up with Platypush, as the application provides several plugins for messaging. Let's
|
||||||
an example where a change in the status of our tests triggers a notification to our Pushbullet account, which can be
|
look at an example where a change in the status of our tests triggers a notification to our Pushbullet account, which
|
||||||
delivered both to our desktop and mobile devices. [Download the Pushbullet app](https://pushbullet.com) if you want the
|
can be delivered both to our desktop and mobile devices. [Download the Pushbullet app](https://pushbullet.com) if you
|
||||||
notifications to be delivered to your mobile, get an [API token](https://docs.pushbullet.com/) and then install the
|
want the notifications to be delivered to your mobile, get an [API token](https://docs.pushbullet.com/) and then install
|
||||||
dependencies for the Pushbullet integration for Platypush:
|
the dependencies for the Pushbullet integration for Platypush:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ [sudo] pip install 'platypush[pushbullet]'
|
$ [sudo] pip install 'platypush[pushbullet]'
|
||||||
|
@ -717,15 +717,15 @@ And here you go - you now have an automated way of building and releasing your a
|
||||||
## Continuous delivery of web applications
|
## Continuous delivery of web applications
|
||||||
|
|
||||||
We have seen in this article some examples of CI/CD for stand-alone applications with a complete test+build+release
|
We have seen in this article some examples of CI/CD for stand-alone applications with a complete test+build+release
|
||||||
pipeline. The same concept also applies to web services and applications. If your repository stores the source code
|
pipeline. The same concept also applies to web services and applications. If your repository stores the source code of a
|
||||||
of a website, then you can easily create automations that react to push events and pull the changes on the web server
|
website, then you can easily create pieces of automation that react to push events and pull the changes on the web
|
||||||
and restart the web service if required. This is in fact the way I'm currently managing updates on the Platypush
|
server and restart the web service if required. This is in fact the way I'm currently managing updates on the
|
||||||
[blog](https://blog.platypush.tech/) and [homepage](https://platypush.tech/). Let's see a small example where we have
|
Platypush [blog](https://blog.platypush.tech/) and [homepage](https://platypush.tech/). Let's see a small example where
|
||||||
a Platypush instance running on the same machine as the web server, and suppose that our website is served under
|
we have a Platypush instance running on the same machine as the web server, and suppose that our website is served
|
||||||
`/srv/http/myapp` (and, of course, that the user that runs the Platypush service has write permissions on this
|
under `/srv/http/myapp` (and, of course, that the user that runs the Platypush service has write permissions on this
|
||||||
location). It's quite easy to tweak the previous hook example so that it reacts to push events on this repo by pulling
|
location). It's quite easy to tweak the previous hook example so that it reacts to push events on this repo by pulling
|
||||||
the latest changes, runs e.g. `npm run build` to build the new `dist` files and then copies the `dist` folder to our
|
the latest changes, runs e.g. `npm run build` to build the new `dist` files and then copies the `dist` folder to our web
|
||||||
web server directory:
|
server directory:
|
||||||
|
|
||||||
```python
|
```python
|
||||||
import os
|
import os
|
||||||
|
|
Loading…
Reference in a new issue