we are facing strange scenario while using jenkins. We have created and scheduled jobs in jenkins and assigned few nodes(Windows Machines) to it and executed! After a week all our jobs got deleted automatically. Is this an expected behaviour of jenkins and do we have a solution for it?. Thanks in advance.
That's not an expected behavior. Try to find out what happened and try to reproduce it. If you can reproduce it, then someone might be able to help you with your issue (if it is still an issue then).
Related
I was writing a test in Karate in VS Code, at some point I made a mistake and afterwards reverted it but when I was running the 'mvn test' command it was still running the wrong version of the code. I decided to delete the feature alltogether but it is still being tested and shown in test results even though the file no longer exists. Is this some issue with cache? If so, anybody knows how can I solve it?
Thank you!
Have you tried deleting the contents of your target folder or try a "clean"
karate -C
Suddenly I'm getting an odd error popping up every few minutes.
'Periodic workspace save.' has encountered a problem.
Could not write workspace metadata '{workspace}.metadata.plugins\org.eclipse.core.resources.snap'.
I've checked and the file is there. It's not marked "read-only".
Nothing's changed recently. I am on a Citrix VM running Windows 7 and my workspace is on a mapped drive. However, this setup has been running fine for over a year.
Any ideas?
I ended up creating a new workspace and moving my projects over there. Fortunately there weren't many (nor did I have too many snippets) and I could recustomize the way I wanted.
This is not a very good solution, however, and I'd love to see a better way to fix this issue.
I'm just a day new at this, so sorry for asking stupid questions...
2 issues...
Can I save a whole project in one file in VS?
I'm trying to run a simple project, but get the error:
Warning 1 Could not copy "obj\Debug\WindowsApplication9.exe" to "bin\Debug\WindowsApplication9.exe". Beginning retry 1 in 1000ms. The process cannot access the file 'bin\Debug\WindowsApplication9.exe' because it is being used by another process. WindowsApplication9
What does "being used by another process" mean?
the project is not open anywhere else when I'm trying to run this, so I don't understand...
Pls help.
Check task manager for an already running WindowsApplication9.exe. You can't build your project if it is still running. Your Me.Hide call sounds like the culprit if your app is running in task manager and you can't see the window.
I had a similar issue to this when attempting to run unit tests. The culprit turned out to be multiple MSBuild processes locking the files. I nuked them via Task Manager, and was able to run my tests again.
the CI server was disconnected for a while for some strange reason from the network and when it came back up, jenkins displayed with no jobs. however in the directory where the jobs live, /var/lib/jenkins/jobs/, the two jobs that should appear are there, but don't show any evidence of existence in the web client.
i tried using the 'copy existing job' and then pointed it to /var/lib/jenkins/jobs/existing_test but it tells me: no such job /var/lib/jenkins/jobs/existing_test
any suggestions as to how to get this to work ?
I know that question can be outdated, but a possible a solution is to run jenkins under appropriate user (the one it run previously). This helped me.
ended up just building the jobs brand new, wasn't able to find a fix
At first I would try and look in the jenkins logs, as your data is in /var/lib/jenkins I would guess your log files are in /var/log/jenkins. Maybe you can find out whats wrong from there.
Also you could try the "load configuration from disk" link in the "manage jenkins" view. That should try to reload the configuration files from your directories, and maybe bring your jobs back. Anyways, you should be able to see something in your logs. If the logs are empty check file permissions, I used to have problems with that after updating sometimes.
I'm trying to work out an automated Build-Deploy-Test workflow using Lab Management/VS 2010 and everything is working ok... except for one small thing.
In my build definition, within the process>environment I set a snapshot that I want the environment to be reverted to before deploying, and this works fine, but when the snapshot is reverted to, the environment is stopped but not restarted.
What results is that the build waits indefinitely for the workflow capability to be available on the environment.
A temporary fix is to just watch and wait for the enivonment to be stopped, and then to start it manually and everything will proceed as expected... but this is hardly ideal.
This is happening to everyone on my team, and none of us have come across a solution. Has anyone else seen this and solved it?
You'll want to take the "Initial Snapshot" when the VM is actually turned on. You can do that, or you can customize the Lab default build process template and include a StartEnvironment workflow activity after the restore snapshot phase.
My suggestion would be to just take the snapshot when the VMs are turned on though. That's the way I have always ended up doing it.