Sometimes it happens that your GitHub Actions workflow fails. When this happens, it is appropriate to check what exactly went wrong before you restart it. Sometimes it could be a timeout or something that was incorrectly configured on the site to test. This issue is precisely the case for my [doctor](https://getdoctor.io) build/test/release GitHub Actions workflow as I do so many
For the new documentation website of [Doctor](https://getdoctor.io), I wanted to do something similar like I did for [Pimp Your Own Bike](https://pimpyourownbike.com/) to show a message depending on the version/branch of the site I am using. For the `doctor` documentation, I wanted to use this method to show a `beta` message when using the beta site ([beta.getdoctor.io](https://beta.getdoctor.io/)). {{}} The beta banner looks like
Comments, just do it. I write this post because I read a couple of articles, and messages on social platforms about stop using comments in your code. In some cases, there is good reasoning behind it, but even with this reasoning, I believe that comments are too valuable for your DEV team. To start this article, I want to tell you
For my VSCode Front Matter extension, I wanted to implement a link that allows you to open the VSCode settings to the extension quickly. {{}} I could not find anything in the documentation but found a reference on Stackoverflow mentioning you could use: `vscode.commands.executeCommand( 'workbench.action.openSettings', '' );`. Using my extension ID was not working correctly. So I did some more digging in VSCode,
GitHub Actions is hot these days, but still, Azure DevOps is being used in many companies, and I do as well. Doctor a tool for publishing your markdown documentation on SharePoint, works nicely on Azure DevOps as well. {{}} ## The credentials To start, you need to choose how you will publish your documentation to SharePoint. Doctor allows three types of authentication. 1.
When creating a whole new Github Actions workflow for [Doctor](https://github.com/estruyf/doctor), I wanted to do as much as possible from one workflow and be able to limit specific actions depending on how it triggered. I wanted my GitHub Actions to run on each push to the `dev` and `main` branch and run the tests on a schedule. Instead of creating two
Let's build together
Manage content in VS Code
Present from VS Code
Engage with your audience throughout the event lifecycle
