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 build/test/release GitHub Actions workflow as I do so many changes
For the new documentation website of Doctor, I wanted to do something similar like I did for Pimp Your Own Bike 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). {{< blockquote type="Related Article" text="#DevHack:
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. Show image Front Matter - Quick link to settings I could
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. infoI will use the doctor sample as the blueprint for this article. The credentials To start, you need to choose how you will publish your
When creating a whole new Github Actions workflow for 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 workflows,
Let's build together
Manage content in VS Code
Present from VS Code
