4 ms·
I have some first-impressions feedback after playing with it for ~15 mins: 1. Setup was super easy. Aside from Goland/Pycharm marketplace search weirdness, I w
by Arbortheus 2y ago
I have some first-impressions feedback after playing with it for ~15 mins:
1. Setup was super easy. Aside from Goland/Pycharm marketplace search weirdness, I was up and running in ~30 seconds.
2. The branch dropdown is a little crazy in some of our repos. We don't have very good branch hygiene, so have hundreds/thousands of branches in the dropdown. I'm unsure how easy of a feature request this is, but it would be nice to order the repos by activity (e.g. most recently committed branch first).
For now, filtering them by my own GitHub user was a fine workaround, as it's then easy to find the workflow run as those /are/ ordered by most recent first.
3. I found a potential bug in the grouping of pipeline step logs. For context, I have a multi-step pipeline. For the first few steps the logs appear on the correct step, but after a specific step the logs appear in the n+1 step's place.
The incorrect indexing seems to be caused by a step that invokes another action via the `uses` block. It looks like this:
- name: Setup foo
uses: ./.github/actions/foo
with:
api_key: <REDACTED>
- name: Build bar
run: make bar
- name: Run baz
run: ./baz
The first part of the logs stating "Run Setup foo" appear in the correct step, but the logs from the "./.github/actions/foo" action appear in the logs for the "Build bar" step incorrectly, and the /actual/ logs from "Build bar" appear in the logs for "Run baz" (so all the logs appear in place of the next step's logs, I guess because the indexes are messed up).
4. If I expand a pipeline's logs with a lot of lines (~67,000 lines) it crashes the extension. (In fairness, in the GitHub actions web UI it says "This step has been truncated due to its large size. Download the full logs from the menu once the workflow run has completed." - so it is a bit excessive.)
Specifically, when I expanded a pipeline step's logs and got "Oops! Something went wrong. We encountered an unexpected error. Try reloading to reset and continue." - when I hit reload it did fix the application, but it loaded the "home" page rather than the pipeline page I was on, and removed all the branch/user filters I had previously entered - it would be nice if these got preserved even if the extension crashes.
If I reopen that same pipeline step's logs I can reliably reproduce this breaking the application every time (tried 3 times).
5. The pipeline logs don't correctly handle symbols and color codes. For example, I have a log that says " YN0000: Successfully set npmRegistries["<REDACTED>"] to undefined", and the "undefined" text appears in grey on the web UI. (I believe the "undefined" comes from GitHub Actions' automatic scrubbing of secrets from the logs.)
In the plugin this log appears as: `[39m YN0000: Successfully set npmRegistries["<REDACTED>"] to [90mundefined`
6. No search functionality or scroll bar on step logs. Suppose my test fails in CI and the result is right at the bottom of 70,000 lines of test logs, I need to be able to easily find that for this plugin to be helpful.
7. After installing the plugin and connecting my GitHub account, I got an error:
"The plugin io.revenate.actionate failed to save settings. Please restart GoLand". However, I think it was a false-positive, because the extension is working just fine without a restart!
- revenate 2y agoThank you so much for your feedback—it’s truly valuable to us. We do our best to test thoroughly before releasing, but we know we can’t anticipate every scenario. The issues you’ve highlighted are extremely helpful, and we’ll be prioritizing them in our next release. Regarding the error you encountered after installing the plugin and connecting your GitHub account—"The plugin io.revenate.actionate failed to save settings. Please restart GoLand"—this does appear to be a false positive. Behind the scenes, we use the built-in IDE mechanisms to persist the selected GitHub account, and sometimes the IDE throws this error when attempting to save the settings file for the first time. This happens because the IDE tries to back up the settings file before persisting changes, and intermittently fails to detect that the file doesn’t exist yet. We’ve already reported this issue to JetBrains. As for your feedback about the lack of search functionality and scrollbar behavior in step logs, you're absolutely right—log search is a critical feature, and it's planned for the very next release. Regarding the scrollbar, our UI leverages the JetBrains embedded JCEF (Chromium-based) browser, and its behavior can vary depending on the IDE version. In some versions, the scrollbar is always present, while in others it only appears when scrolling. This behavior is controlled by the underlying JCEF implementation, and we’ve also raised this issue with JetBrains. We sincerely appreciate you taking the time to share your thoughts, and your feedback helps us improve Actionate to better serve our users. Please keep the suggestions coming—we love hearing from you!