karmats / gocd-monitor Goto Github PK

Using Electron to develop a desktop-end version, I think it should be easier to use than running the command to build and run the server then open URL in the browser.

• Use Electron to host the server
• Use Electron to display the dashboard
• Config gocd url and user/password in UI.

add-flexbox, add-roboto-font, and add-material-icons (at least) all fail on Windows. Please, modify package.json scripts to make them platform agnostic.

"add-flexbox": "cp node_modules/flexboxgrid/css/index.min.css assets/stylesheets/flexboxgrid.min.css",
"add-roboto-font": "cp node_modules/roboto-font/fonts/Roboto/* assets/fonts",
"add-material-icons": "cp node_modules/mdi/css/materialdesignicons.min.css* assets/stylesheets/ && cp node_modules/mdi/fonts/* assets/fonts"

In my current team, we are only interested in a few of the pipelines in GoCD (our our own teams' pipelines plus a few shared ones, not other teams' pipelines) so we set up a regex to filter out whatever we aren't interested in, expecting it would also filter any new pipelines that might pop up in the future (which happens quite regularly in our case).
Unfortunately, digging deeper into the code, I found that this doesn't happen. The regex is only used in the actual configuration step to determine disabledPipelines.

I'm happy to submit a fix for this but I'm wondering what the intended behaviour should be.
My intuition would say filter by regex, then remove any left-over disabled pipelines. However, you could also do either regex or disabled pipelines.

Any opinions?
Apart fom that, any good ideas how to make the behaviour more obvious to the user?

Somewhere in the dependency try there is a malicious version of [email protected]

for more info, see #dominictarr/event-stream#116

the result is, that new installation will not install, you may not notice it, if you are using already cached dependencies

I think its because the Api's have changed in the new GOCD version

I have a few deploy pipelines, that isn't started by any changes... Instead, they're manually triggered.

https://s14.postimg.org/rabkajk35/Triggered_Go_CD.png

GoCD shows it just fine, by gocd-monitor, don't.

https://s11.postimg.org/3ouu1ww03/Triggered_Go_CDMonitor.png

What am I doing wrong?

Thanks! :)

When the configured user only has "view" permissions, but not "operate", all of the pipelines appear paused. The monitor determines whether or not the pipeline is paused by looking at the "can_run" key from the pipelines API, but this key is never true if the user doesn't have operate permissions. So as a result, all of the pipelines are displayed as paused.

As a matter of security, it would be preferable to function with as few permissions as possible.

The authoritative way to determine if a pipeline is paused would be via the dashboard or pipeline status API.

Great monitor btw. Thanks!

As per readme I start the server using npm run dev-start , but there seems to be no web server running. The process end with webpack: Compiled successfully, but nothing is running on port 30000 or 30001.

Can you please update the documentation so that we can better contribute to the development of this project?

Hi there, first of all, great tool, it would be great to show the Duration of the pipeline, maybe next to when was build

if you want I can try to PR

thanks!

I have tried building with a lot of different node versions in different docker images, but I always get the same problem.

Dockerfile variants I have tried:

FROM nodesource/centos7:5.8.0
# cache package.json and node_modules to speed up builds
ADD package.json package.json
RUN NODE_ENV="" npm install
# Add your source files
ADD . .
CMD ["npm","start"]

FROM node:onbuild
EXPOSE 3000

FROM node:6-onbuild
EXPOSE 3000

FROM node:4-onbuild
EXPOSE 3000

Different teams prefer different themes (light or dark). It would be nice if we have an option to change the theme through admin settings.

The screenshot in the readme shows builds being displayed in a table format, with multiple icons per row.

When running however, builds are displayed 1 icon per row. Which means you have to scroll constantly, how do you change the layout?

Hi there,

some months ago, we used to have a older version of GoCD server running with the then-current version of gocd-monitor and could monitor our pipelines with it. In the meantime, the GoCD server has been updated several times (now 21.2.0 (12498-16e1ac6956cd5177a99dc3fe33503661881c354f)) and things stopped working. The log repeats every second:

[2021-09-07T09:57:26.416Z] INFO Retrieving pipeline names
[2021-09-07T09:57:26.788Z] ERROR Failed to retrieve pipeline names
[2021-09-07T09:57:26.789Z] ERROR Failed to retrieve pipeline names, retrying
[2021-09-07T09:57:26.789Z] ERROR StatusCodeError: 404 - ""

Updating to the latest gocd-monitor didn't help. Any ideas what might be causing this? We were thinking of permission problems, but that doesn't seem to be the problem...

Thanks!

I'm currently working in a set-up where multiple teams are using the same GoCD instance but are responsible for different parts of the system and therefore interested in different pipelines. Some pipelines are of interest for multiple teams while other pipelines are only interesting for a single team.

At the moment, we deploy one instance of gocd-monitor for each team. This works OK but is a big overhead, esp. as the number of teams grow. Therefore, it would be nice if gocd-monitor would support multiple teams out of the box.

Two approaches I can think of:

• Store settings for multiple teams and give them a way of selecting their set of settings. This is more or less straightforward to implement since it extends the current concept quite nicely. However, it's still shared state: ones change influences others, teams need to know who is using which settings-set, ...; Also, the state needs to be persistent, making immutable infrastructure a bit harder.
• Define settings in URL: This seems to be more complex since the current code-base isn't really intended to do this so probably needs some refactoring. Also, if this is added to the existing, persistent settings mechanism it becomes quite hard to reason about (both for developers and users): What happens if I have one setting in the URL but then change it in the UI? What if some settings are defined in the URL and others aren't? What if something is defined in both?