• Activity
  • Votes
  • Comments
  • New
  • All activity
    • Showing only topics with the tag "open source". Back to normal view

    8. A bunch of updates and fixes from open-source contributors

      ~tildes.official Text 324 words
      Over the last week, a number of updates have been made by people other than me contributing code to Tildes through its open-source repository. I wanted to make a post to highlight some of these...

      Over the last week, a number of updates have been made by people other than me contributing code to Tildes through its open-source repository. I wanted to make a post to highlight some of these changes and let everyone know about them, since there are some great updates and fixes in here:

      @deing made it possible to create links that will pre-fill the subject and message for private messages. For example: https://tildes.net/user/Deimos/new_message?subject=Test+Message&message=Please+don't+actually+send+this+to+me

      @blitz saw me make an offhand comment about a rare bug when someone submits a link to an IP address, and got a development environment set up and fixed it right away.

      @Bauke has been on a tear, fixing a lot of long-outstanding issues and adding features. So far:

      • Added a way for users to view their two-factor authentication backup codes (previously you could only see them at the time you activated 2FA).
      • Added "View Markdown" for comments and text topics. This is inside a new "More" dropdown menu, and will show you the markdown that the poster used, so that you can check how they did some formatting or copy-paste if you want to use someone else's post as a template of sorts.
      • Added new settings (under "Site behavior settings" on the Settings page) to always open links to Tildes groups and users in new tabs.
      • Fixed a few issues with inconsistent interface elements and styling.

      There are multiple more merge requests still waiting for me to review, and I'll probably be making some other posts soon once some of those get merged in as well. Thanks, the contributions are greatly appreciated! If anyone else is interested in looking into contributing, the CONTRIBUTING file in the repo is probably the best place to start.

      And as usual, I've topped everyone back up to 10 invites, accessible on the invite page.

      53 votes

    41. Looking for advice on a CI / regression testing platform

      ~comp Ask (advice)
      Hi all, I'm looking for some advice regarding how to set up a basic CI regression / testing suite. This isn't my full time job, but a side project my group at work wants to spin up to... shall we...

      Hi all,

      I'm looking for some advice regarding how to set up a basic CI regression / testing suite. This isn't my full time job, but a side project my group at work wants to spin up to... shall we say, give us a more real time monitoring of functionality and performance regressions coming out of the underlying software stack development (long story).

      As none of us are particularly automation experts, I was looking for some advice from my fellow Tilderinos. Please forgive me if any of the below is obvious and/or silly.

      A few basic requirements I had in mind:

      1. Can handle different execution environments: essentially different versions of the software stack, both in docker form and (eventually) via lmod or some other module file approach (e.g., TCL), and sensible handling of a node list.

      2. Related to one, supports using the products of builds as execution environments. Ideally we'd like to have a build step compile the stack and install it to a NFS from which we can load it as a module.

      3. Simple to add tests. Again, this isn't our full time job -- we mostly want to add a quick bash script / makefile / source code or the like to the tests when we run into an issue and forgot about it.

      4. Related. We should be able to store the entire thing as a git repo. I have seen this to some extent with Travis, but my experience with Jenkins was... sub-par (is there a history? Changelog? Any way at all of backing up the test config?).

      5. Some sort of post-processing capabilities. At a glance we need to be able to see the top line performance numbers for 20-30 apps over the different build environment. Bonus points if there's a graph showing performance vs build version or the like, but honestly a CSV log file is good enough.

      6. Whatever CI software we get has to be able to run this locally. Lots of these are internal only numbers / codes. FOSS prefered.

      7. A webui for scheduling runs / visualizing results would be nice, but again this could be a bash script and none of us would bat an eye.

      Any thoughts would be greatly appreciated. Thanks!

      7 votes