I want to use build widget of Hygieia Dashboard for Jenkins, but not able to populate data in it.
Installed Mongo.
Downloaded Hygieia V1.2.0.
Successfully ran mvn clean compile install package.
Created application.properties in corresponding config folders for Hudson Collector.
Run hudson collector with java -jar
Run gulp serve in the UI folder
Everything appears to come up ok
I see data has been created in mongo
I can add a dashboard in the UI .
But, I can not succesffuly add Build widgets for Jenkins via the UI.
this is the widget dashboard and we are using build widget-
this is the widget dashboard and we are using build widget
on click of configure and adding the server and jobname , it is getting logged out. Below is the snippet-
on click of configure and adding the server and jobname , it is getting logged out
Automatically it is coming to login page-
Automatically it is coming to login page
And after logging again to the widget dashboard, we are getting build widget with no data-
build widget with no data
Now, when I checked in db, I am getting all the jenkins jobs in collector_items.
But not able to show it in build widget.
This is a very common issue with all widgets in Hygieia. The only way to get it running is to let the collectors run for some time untill data is populated in the database and then restart the entire process including the UI Server and the Collectors & API service. Still if you cant see the data populated try removing the widgets and adding it again and leave the UI page as it is on the screen for 5-10 minutes, your data will be there.
This usually occurs initially when we are configuring a new collector for the very first time.
Related
I have developed a small appointment system using Laravel and Vue.js. For deployment purpose, this system has been deployed using Vapor(https://vapor.laravel.com/) and AWS. While the deployment has been successful i.e I can see the login page, login successfully and even perform some functions. However most of the navigation links are not working. The errors that I see in browser console : ChunkLoadError: Loading chunk XY failed at path https://hosturl/js/[file].js
Before deployment when I execute npm run production, I can see that files are being generated in root/public/js. But after deployment the system seems to be unable to find/access them. All the routing has been handled using vue router in the development.
Is this issue somehow related to webpack.mix.js or is the expected folder structure different after being deployed? Am I missing something important here that is needed for production? I am new to Vapor and AWS so help will be really appreciated.
I have Cypress tests failing only on Github CI with this error:
Your page did not fire its `load` event within `60000ms`.
I assume this is because the Cypress browser is stuck loading something Github Actions environment is blocking. Tests run fine locally. However, because I do not have access to the browser console, I cannot know what is causing the error.
Based on Cypress the service screenshot the page loaded fine, though.
How can I either
Disable load event check in my Cypress tests, as I assume this is not a real issue
Access JavaScript logs or Network tab logs though Cypress service to confirm what could be the issue in Github Actions run-time environment
This is a SvelteKit based site.
It's not currently possible to opt-out of waiting for the load event: https://github.com/cypress-io/cypress/issues/788
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
I am developing a website using MVC 3,
I have a web setup project for installing it to my localhost.
Now what I want is to create an EVENT SOURCE ( where I will later on log using my website ) using this very setup.
Is this possible?
I have been following this link:
http://msdn.microsoft.com/en-us/library/ms998320.aspx#paght000015%5Feventlogaccess
I earlier tried creating an EVENT SOURCE programmatically, but my web app threw security exceptions, similar to the error the user in this post was getting: System.Security.SecurityException when writing to Event Log
Thanks in advance
Yasser
After a lot of struggle I myslef managed to answer my question
I first had to create a seperate installer class, which had code to install an event source.
Next in my web setup project, under custom action in INSTALL, I simply added the output of the above project which was a single dll.
and thats it!
Now whenever my web setup runs, the installer dll is also activated and run and my event source gets created.
Now that was not too difficult was it ? ;)
Summary
When using IntelliJ IDEA to debug a JSP, I'm seeing the JSP get triggered twice before the actual request from the browser. Does anyone know why?
Updated with servlet test below.
Overview
I'm using (evaluating) IntelliJ IDEA for (effectively) the first time. When doing web application debugging, I'm seeing an odd behavior that suggests to me I have something misconfigured somewhere: If I have a breakpoint set in code that will run in response to the startup page, the code runs twice before the browser is launched, and then a third time in response to the browser request. I'd like to know whether I may have gone wrong somewhere (or if I haven't gone wrong, what's going on).
The Setup
A) Created a new web application project
Created a new project from scratch
Gave it a name and identified it as a Java module
Accepted the default src directory
Chose "Web Application" from the Desired Technologies list
That gave me a standard structure (src, WEB-INF, etc.) with a default index.jsp in it.
B) Added some simple code to the JSP to output the date.
C) Put a breakpoint in the code.
D) Configured my web browser in File | Settings | Web Browsers
E) Went to Run | Edit Configurations... and:
Clicked [+] | Tomcat Server | Local
Gave it name
Clicked the Configure... button next to the drop-down list of application servers (since I didn't have any yet) and pointed it at my standalone Tomcat6 server (see below), accepting all the defaults
Back in the debug configuration, told it to deploy the "war exploded" artifact for this configuration
Added a "?foo=bar" query string to the default startup URL, so: http://localhost:8080/?foo=bar (you'll see why below)
Left everything else at defaults
Clicked OK
The Run
Choose Run | Debug. It happily starts up the Tomcat server.
It hits the breakpoint. Examining the request shows that this is a GET from user-agent "Java/1.6.0_20". It has the query string configured above. No attributes, no parameters other than the query string one.
Click Resume Program button (F9).
It hits the breakpoint again. This is also a GET from user-agent "Java/1.6.0_20", but it does not have the query string. No attributes, no parameters.
Click Resume Program button (F9).
It launches the browser and hits the breakpoint again. This is a GET from the browser (with the query string) and looks perfectly normal.
I see the behavior both with and without the query string, I just added it to see when/whether it showed up.
If I create a class and use that class from the code in the JSP and move my breakpoint into the class's code, that breakpoint does get hit all three times, so if it were doing real work (looking something up in a database, for instance), it would really do the work. I wondered if this was some phantom pre-compile call or something, but A) it shouldn't be, and B) it doesn't seem to be.
Run with Servlet
I wanted to tease out the behavior a bit more, so I added a servlet to the project, mapped it to the path /foo, and changed my debug configuration to trigger http://localhost:8080/foo?foo=bar rather than the index page. I also added another JSP to the project, at the root, called another.jsp. This revealed very interesting behavior:
Choose Run | Debug. It happily starts up the Tomcat server.
It hits the breakpoint in the servlet code. Examining the request shows that this is a GET from user-agent "Java/1.6.0_20". It has the query string. No attributes, no parameters other than the query string one.
Click Resume Program button (F9).
It hits the breakpoint in the index.jsp(?!). This is also a GET from user-agent "Java/1.6.0_20", but it does not have the query string. No attributes, no parameters. Note that index.jsp has nothing to do with the startup path /foo.
Click Resume Program button (F9).
It launches the browser and hits the breakpoint in the servlet again. This is a GET from the browser (with the query string) and looks perfectly normal.
The breakpoint in the another.jsp file is never hit. So I suspected the triggering of the index.jsp (with no query string) relates to it being the default "welcome file." So I added a welcome-file-list to my web.xml and set up another.jsp as the only welcome-file. Sure enough, now the breakpoint in another.jsp gets hit, and not the one in index.jsp.
More Details
Fairly generic Ubuntu 10.04 LTS desktop install
Freshly downloaded and unpacked IntelliJ IDEA Ultimate installation (30-day trial)
Freshly downloaded and unpacked standalone Tomcat6 install (IDEA didn't like the central install I'd done via Synaptic, the split directory structure confused it, so I stopped that server and just used a simple download-and-unpack version)
Sun's Java 6 JDK
Thanks in advance!
Examining the request shows that this is a GET from user-agent "Java/1.6.0_20".
That happens when you deploy the webapp on ROOT of Tomcat. The Tomcat server Eclipse plugin will do a self-test on / during startup (which indirectly loads the welcome-file as definied in web.xml).
What can you do? Either live with it or deploy on a context other than ROOT.