Do you agree that products always have room for improvement?
"Every day there are little things in software that we find annoying. Some write books about it, like Annoyances.org, but I thought this site would be more constructive.
BetterSoftwareSuggestions.com is proudly maintained by myself and the developers at SSW."
- Adam Cogan GitHub gives you 2 ways to directly send your suggestions:
It is important that we can rely on the GitHub audit logs telling us who did what.
In this case I know some repos were transferred into SSW Consulting, but I don’t know who clicked the “Accept” button.
In the below UI, that person should be listed, so I know who to talk to.
Replying to an Issue via email is a great feature as it saves you opening GitHub – you can reply without leaving Outlook.
The problem is the messages will include a lot of noise (sometimes blank spaces) with the email history and irrelevant data, which makes them hard to follow in GitHub…
Suggestion: Clean up email replies by keeping only the body of an email (no history, no extras)
See the replies in this Issue that were sent via email: https://github.com/SSWConsulting/SSW.People/issues/507#issuecomment-1692676860
Related links:
OIDC is the recommendation method to login to Azure from GitHub pipelines now as it provides better security and doesn’t rely on storing a secret.
Currently OIDC login tokens expire in just 5 minutes🔥, causing long running scripts to fail.
Related GitHub Issue: https://github.com/Azure/login/issues/180.
Your Azure credentials have not been set up or have expired,
1955 | please run Connect-AzAccount to set up your Azure credentials.
1956 | ClientAssertionCredential authentication failed: A
1957 | configuration issue is preventing authentication - check the
1958 | error message from the server for details. You can modify the
1959 | configuration in the application registration portal. See
1960 | https://aka.ms/msal-net-invalid-client for details. Original
1961 | exception: AADSTS700024: Client assertion is not within its
1962 | valid time range. Current time: 2022-10-20T07:47:12.7446078Z,
1963 | assertion valid from 2022-10-20T07:37:08.0000000Z, expiry time
1964 | of assertion 2022-10-20T07:42:08.0000000Z. Review the
1965 | documentation at
❌ Bad example – Error on deployment – assertion valid from 2022-10-20 07:37 to 2022-10-20 07:42 🔥(5 minutes)
- uses: azure/login@v1
with:
client-id: ${{ env.CLIENT_ID }}
tenant-id: ${{ env.TENANT_ID }}
subscription-id: ${{ env.SUBSCRIPTION_ID }}
enable-AzPSSession: true
❌ Bad example – Needs 1 more parameter – (e.g. token-expiry: 30M)
- uses: azure/login@v1
with:
client-id: ${{ env.CLIENT_ID }}
tenant-id: ${{ env.TENANT_ID }}
subscription-id: ${{ env.SUBSCRIPTION_ID }}
enable-AzPSSession: true
token-expiry: 30M
✅ Good example – Allow the token expiry to be set to a more reasonable time
There have been awesome improvements to the GitHub Actions “New Workflow” screen as per the blog: Getting started with GitHub Actions just got easier!
When adding a GitHub action for a Gatsby GitHub project, in “Deployment” it prompts to “Deploy Node.js to Azure Web App” even though it should suggest these 2 resources:
When adding a GitHub action for an Azure Bot Framework GitHub Project, in “Deployment” it prompts to “Deploy .NET Core app to an Azure Web App”, it should also suggest resources like
When I look at a list of closed Pull Requests, I can see easily see who created them, but not who approved them…
Currently, I need to click on each PR to see who approved them; or add a filter “reviewed-by:” if I want to see all items approved by a specific person…
For markdown users who use content + images and Pull Requests on content sites E.g. SSW Rules
If you agree, please:
Developers are happy with the code view however when you are working with Markdown, you want to see a more realistic view of outputted HTML like this:
I discovered a possible UX issue when modifying a GitHub Pull Request using the iPad App.
There are multiple popups that appear, which is noisy and unintentional.
I wonder if this is the intended UX… I am aware one benefit of this UX is that the user knows which popup to read first.
I found an issue when using the GitHub App on the iPad when reviewing a Pull Request.
It’s not clear to see the changes and for small grammatical changes the web view is required.
