I need to be able to set the tags for a runner during the registration process, or right afterwards via the CLI in an Amazon Linux instance. I haven't been able to find any documentation for doing so and have attempted several potential methods that have all failed. Does anyone know how adding tags can be accomplished from the CLI, not in the admin/runners UI?
Ideally, we would also like to be able to disable 'Run untagged jobs' for the runner so that the runners will only pick up similarly tagged jobs.
Related
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 am trying to use the EC2 plugin from jenkins to launch a slave agaent instance on AWS EC2. However I want to be able to specify my security group and as of right now it forces me to choose default. Does anyone know a workaround for this?
I looked on git and apparently there was a pull request for this feature. I'm not very familiar with it but it did say it was closed so does that mean it never got commited?
Thanks in advance!
It's not tested or anything, but my fork has security groups as of today.
https://github.com/jmoses/ec2-plugin
There's also no downloadable .hpi in the repo, so you'd have to build it. I'll probably upload one at some point, or drop me a message and I can shoot you the one I've got. Work in progress.
i have a question. I use VSS (SourceSafe) Plugin in Hudson. But I don't have rights for a file. If I start my job, I have the following error: "Access to file ... denied" and Hudson stops the build. How can I ignore this error and continue the build ? Thank You in advance.
Without knowing the specifics, you will have to tell Visual SourceSafe to ignore that file for the specific user being used so that the file isn't retrieved when the job is started. Otherwise, you will have to get the necessary permissions to retrieve the file. I doubt there is anything you can do in Hudson to prevent the build from failing.
The plug-in configuration allows you to specify the user that accesses the SourceSafe repository. Normally what you should do is create a CI/build user and use that information to get access to any files involved in the build.
You can verify the user has access by attempting to open the 'srcsafe.ini' file over the network using that same information. If it works, you should be able to retrieve files from VSS via Hudson. If it doesn't, then you'll have to poke around more in your environment.
Basically, just make sure you can get things running manually first using the same account information before you try and integrate your build into Hudson.
I have bit of experience in running a simple build upon every SVN commit (it is a piece of cake)
Regarding deployment of the war to a remote production server via
Hudson, there seem to be some alternatives:
use the 'deploy' target in the app's build.xml
use the deploy-plugin of Hudson
which I fail to get working :(
What is the simplest way to do a remote deployment to Tomcat?
Are there any examples available?
And what about release management? How do we tag our releases in
your SCM?
I use Maven for builds.
Since I am working with WAS I use the WAS Builder Plugin for deployment. However, I could also just fire up a batch/shell script for deployment. My current approach is to use slaves that run on the target machine where I want to deploy and assign my deployment jobs to them.
For tagging you can use whatever you prefer. The are 3 basic options:
Let maven do it
run a command line command
use a Hudson plugin
We use subversion, so the Subversion Tagging Plugin would be a natural match. However, we don't use Hudson for tagging right now. However, there are several plugins out there for different SCMs. I usually prefer a plugin over a command line, one reason is that company policy forbids to store passwords unencrypted and it is usually fairly easy to configure.
Our strategy has been to combine the promoted builds plugin and the deploy plugin in hudson. Then, when something is "promoted," send an email and do the deployment. The deployment plugin is cargo based and works with a variety of web and app servers.
Maybe post a little info about why the deploy plugin isn't working for you?
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.