What does gitlab do in CI/CD process at pending state?
I'm using specific runner and it gets stuck at pending state for so long until running, even my internet connections work well.
Can anyone explain to me what exactly happened in CI/CD pending state?
In your specific case, I could think of two possible reasons.
Case 1. No gitlab runner registered with your repository.
-> Solution: On your gitlab repository(project) page, go to Settings -> CI/CD -> Expand Runners sections. Then check if there are Runners associated with your repository. If there are, you need to check two things.
Check 1: Are the runners active?
Check 2: Are the tags associated with the specific runner being used as a tag in the pipeline job you are running.
Case 2. Runner cannot connect to your gitlab repository.
-> Check the network settings of your runner. Enter the runner server, and try to clone your project from there (see if it can connect to gitlab). If you are running your runner in your own PC, see if your proxy settings might be interfering with the connection.
Related
I have set up 3 CentOS 7 VMs to test out the OS patch management feature that is now available in GCP. I deployed the patch manager agent and the Patch Management console reports all 3 VMs have "Important / security updates available". I then scheduled a Patch deployment job for CentOS and it ran on all 3 machines.
When I check the logs, I can see that the task began at the scheduled time and reports "No packages to update".
An hour later, the dashboard still reports: "Important / security updates available".
I have rebooted the VMs and the dashboard still has not changed and it shows 100% of the VMs requiring patching.
While I suspect that there really IS no security update available, I am not sure how we can trust the dashboard. Further, there are no hyperlinks available for more information about what these important/security updates are so how would you even know what fixes were going to be applied if there were any?
I was able to reproduce this error in my own project.
I created a VM Instance with CentOS 7, then I created a new patch development,
It is worth mentioning that I used 'Minimal and Security updates’ on the Patch Config menu:
Then I received the same message:
But I was able to fix it.
I have found the following documentation: What is included in an OS patch job?
Where it is mentioned that:
For Red Hat Enterprise Linux and Centos operating systems, you can apply all or select from the following updates:
System updates
Security updates
So I created another patch development, but in this case, I didn’t select the ‘Minimal and Security updates’ I just kept it blank, in this way its select the default value, and it applies all the updates instead of only the minimal and security updates.
And it worked.
We need to use the Github action self-hosted runner because we need to have an access to the on-premises resource.
I understand that we can run the self-hosted runner on VM or the docker container.
Can we run the self-hosted runner on-demand? Like the Github-hosted runner that always use the clean isolated VM and is destroyed at the end of job execution. Or like the job agents on Azure DevOps/Github that created the clean job agent container to run the pipeline and gets deleted at the end.
Can we do something similar with Gihub-action self-hosted runner? E.g. Allow us to register a VM with the Docker engine or Kubernetes cluster as a self-hosted runner. When I run the Github workflow, it should start a container and run the workflow inside that container. After that, it should delete the container.
Is it possible to do that now? I am not sure if there is a roadmap document somewhere for Github action.
If you use AWS, you can try ec2-github-runner. It does exactly what you're looking for.
I believe the same approach can also be implemented for the other cloud providers.
GitHub itself doesn't provide such capabilities at the moment.
I think the question is a little bit misleading but, if I understand properly, what you are trying to achieve is to have stateless GitHub Actions workflow run execution in your self-hosted runner. Unfortunately, this is currently impossible. Only GitHub-hosted runners work the way you describe. According to the documentation:
GitHub-hosted runner is always a clean isolated virtual machine, and it is destroyed at the end of the job execution.
You can read more about the differences between each runner type here.
I've just learnt about GitHub Actions and I think it's super fantastic.
One thing that struck me hard at the beginning was, when I was setting up the self-hosted runner, GitHub asks me to run a bunch of command on my local machine which apparently is in private network and it's not exposed to the internet (inbound - meaning the www cannot reach it).
However, after installing what GitHub asks me to install, it seems like a webhook is set up successfully and every time there's push/merge to my master (set up in GitHub action file), the worker from my computer knows and start pulling the newest version of the repo and start installing dependencies and other CI/CD stuff.
Now what I'm curious is how does GitHub actually talks to my VM while it's in a private network?
I've never been a networking guy, so I'm not so sure why this is possible. But it's fascinating.
It's not that GitHub is connecting to your self-hosted runner (inbound) but the self-hosted runner itself connecting to GitHub (outbound). This is why it works. It's your VM (with the runner in the private network) talking to GitHub. The communication direction is reversed. After your self-hosted runner connects to GitHub, both parties keep the connection open. That allows all the events to be pushed to your runner through the connection by the GitHub repository if something happens (PR is opened, a commit was made, etc...). The connection remains open while the runner is operating. Of course, if something bad happens to the network and the connection is broken the communication will stop working. To fix that the runner periodically sends ping packets to GitHub to validate the connection is working and attempts to reconnect if it's not.
You can read more about the communication workflow in the official documentation.
Howto configure system to have one master and multiple slaves where building normal c-code with gmake? How slaves can access workspace from master? I guess NFS share is way to go, but if that's not possible any other options?
http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds is there but cannot understand how workspace sharing is handled?
Rsync? From master: SCM job -> done -> rsync to all slaves -> build job and if was done on slave -> rsync workspace back to master?
Any proof of concept or real life solutions?
When Hudson runs a build on a slave node, it does a checkout from source control on that node. If you want to copy other files over from the master node, or copy other items back to the master node after a build, you can use the Copy to Slave plugin.
It's surely a late answer, but may help others.
I'm currently using the "Copy Artifact plug-in" with great results.
http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
(https://stackoverflow.com/a/4135171/2040743)
Just one way of doing things, others exist.
Workspaces are actually not shared when distributed to multiple machines, as they exist as directories in each of the multiple machines. To solve the coordination of items, any item that needs distributed from one workspace to another is copied into a central repository via SCP.
This means that sometimes I have a task which needs to wait on the items landing in the central repository. To fix this, I have the task run a shell script which polls the repository via SCP for the presence of the needed items, and it errors out if the items aren't available after five minutes.
The only downside to this is that you need to pass around a parameter (build number) to keep the builds on the same page, preventing one build from picking up a previous version built artifact. That and you have to set up a lot of SSH keys to avoid the need to pass a password in when running the SSH scripts.
Like I said, not the ideal solution, but I find it is more stable than the ssh artifact grabbing code for my particular release of Hudson (and my set of SSH servers).
One downside, the SSH servers in most Linux machines seem to really lack performance. A solution like mine tends to swamp your SSH server with a lot of connections coming in at about the same time. If you find the same happens with you, you can add timer delays (easy, imperfect solution) or you can rebuild the SSH server with high-performance patches. One day I hope that the high-performance patches make their way into the SSH server base code, provided that they don't negatively impact the SSH server security.
I am setting up a number of slaves to my Hudson master, grouped by labels. I would like to be able to have a set of nodes that run during the day and an additional set of nodes that are turned on during the evening.
Is this possible, either directly by hudson or via plugin or script? If so what is your recommended solution?
There is an experimental feature to schedule when each slave should be available. It is in core, but you have to set a system property to enable it. So if you start Hudson with
java -Dhudson.scheduledRetention=true -jar hudson.war
You will get an extra configuration option on each node, allowing you to specify a schedule of when that node should be used.
Let the OS (or any other scheduler) control the start and stop of a node. Hudson only uses what's available. Not sure how Hudson acts if a node dies while running a job.
Update: The feature that Michael Donohue is not experimental anymore and is available for all nodes (I use the SSH node). Works great (at least the take only if needed feature).
Expanding on what #Peter Schuetze said...
Unless the nodes are VMs that you want Hudson to manage (see the VMware plugin), the start and stop operations are out of Hudson's control. Depending on how you have your slaves set up, Hudson may just automatically connect when it sees the node is online, or you may need to make sure the slave runs something at startup.
You can use the Hudson API (generally HTTP POSTs to URLs on the Hudson master) to tell Hudson that nodes are going offline ahead of time. This will help avoid builds that get killed when the node goes down. Check out the HTML source on the node's page (http://hudson/computer/node_name) to see what the web interface does for the "mark offline" and "disconnect" operations.