I have a repository on Github that contains a notebook I'd like to run automatically. I've looked at this action, which seems useful, but I'm not quite sure how my actions.yaml file should look, as I'm pretty new to Github actions.
Example 1 and Example 2 sections of this Github action's author is an example of what your Github action workflow file should look like.
Since you're the user of this Github action, your repository will contain your workflow file under your .github/workflows directory. Your workflow action file can be named anything, as long as it's sitting in this location; i.e it doesn't have to be named actions.yaml
For another example, you can review the workflow file at my repository, again under .github/workflows. This makes use of another action (and it's currently all commented out as I don't want to run it right now), but you will get the idea and it can help you generalize and understand what goes into a workflow file.
Related
I have a bash file in my template repo, it contains the url of current repo, what i want is when another user use this template, in their repo should be contain their new git url repo
i don't know where to start or what to search...
Doesn't seem to be possible as of now:
There's nothing in the offical docs.
And searching for it turns up sources saying that it isn't possible at the moment:
Now that github has template repositories, an obvious next step is to enable "variables" to make it easy to stamp out customized repositories based on a set of metadata passed in to the template.
Source: https://github.com/isaacs/github/issues/1716
Hey! As far as what I have read, this is not possible. It would be awesome to see this get added. I think the best thing we can do at this point is to add a feature request.
Source: https://github.community/t/variable-substitution-for-github-template-repository-usage/2881
I'm developing a Jupyter Book project with my research team on a GitHub repository (I'm a total noob at this but so are they).
Yesterday I came across a few PRs and realized that they all included a '_build' folder in their forks which gets added to the repo when you test jb build MyBook locally on your clone. I'd like to set up a bot, perhaps with GitHub Actions or ProBot that checks this and either removes the folder from their fork (No harm there) or leaves a comment that the folder should be removed before merging. (The book gets built and deployed by a GitHub-actions workflow)
As far as I can tell, bots of this kind can only check for title, body, and comments but not the contents of the fork itself. Are there tools out there to do this? If not so, please point me in some direction so I can further investigate the matter and perhaps create a workflow of my own.
Thanks in advance!
Beside adding a .gitignore, as commented, to incite any contributor to not add a folder, you might consider writing your own GitHub Action in order to reject automatically a PR if the wrong folder is detected.
You can use a GitHub Action like ArangoGutierrez/GoLinty-Action and adapt it in order to check for a folder in the checked out code.
If the test fails, you can then reject the PR.
I feel like this question must have been asked before, but I'm not finding it on here. I have a file that I want in a GitHub repo, in this case a file in which the user would paste their API keys after cloning. I want this blank file to be cloned down, but I don't want it to be tracked or pushed. I already have it listed in the .gitignore file that is contained in the repo, yet after pulling and modifying the file, git status still shows the file as being tracked and having changes that need to be committed. How can I get around this?
You could do something like this via Github Enterprise's pre-receive hooks functionality.
From the readme, you can create a pre-receive hook that:
Prevents sensitive data from being added to the repository by blocking keywords, patterns or filetypes.
When you create a Github Organisation or a Bitbucket Team/Project, one of the configuration items is:
Project Recognizers: Pipeline Jenkinsfile
There are no other options other than "Pipeline Jenkinsfile", however the fact that the option is even there suggests that the developers envisage people writing their own custom 'recognizers' for projects that don't have a single 'Jenkinsfile' in the top directory of the repo.
Can anyone point me in the direction of any other project recognisers that can be installed and used, or even some details on where to start to implement my own recogniser?
My particular use-case is that within a single repository, we define several workflows that orchestrate actions over code / configuration in the one repo, and I would love to be able to use the Bitbucket Team option to dynamically scan the repo, find all the *.Jenkinsfile files across all branches / pull requests and populate the necessary pipelines.
For example, in the repo are the files:
/pipelines/workflow1.Jenkinsfile
/workflow2.Jenkinsfile
/workflow3.Jenkinsfile
I would like jenkins to create the folder structure:
/team/repo/workflow1/master
/dev
/PR1
/workflow2/master
/dev
/feature-xyz
Any thoughts on where I could start with creating a Project Recognizer to do this (if this is even possible) ?
I think you can do that with providing several Project Recognizers with different names, for example:
Project Recognizers
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow1.Jenkinsfile (or path to the file that contains valide Pipeline steps.
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow2.Jenkinsfile (or path to the file that contains valide Pipeline steps.
=========================================
**Pipeline Jenkinsfile**
Script Path: pipeline/workflow3.Jenkinsfile (or path to the file that contains valide Pipeline steps.
Another option here, could be Pipeline Shared Groovy Libraries Plugin, more details about this plugin can be found at Extending with Shared Libraries.
This approach gives you ability to use your custom scripts (Classes, steps, etc.) which means that you can define your own flow depending on repo name, project name, etc.
As of now, there should at least be the option to provide an alternative recognizer for the Jenkinsfile. This was added in JENKINS-34561 - Allow to detect different Jenkinsfile filenames. You can see the pull request at jenkinsci/workflow-multibranch-plugin/pull/59 which may help provide some background information in how the recognizers work.
In terms of multiple being recognized from a single source, JENKINS-35415 - Multiple branch projects per repository with different recognizers and JENKINS-43749 - Support multiple Jenkinsfiles from the same repository are requests that are very similar to this one.
A comment from Stephen Connolly in JENKINS-43749 says this about it:
What this is asking for is, instead, to create a computed folder with a pipeline job for each jenkinsfile within the branch.
I think the APIs should support that if somebody wants to take a stab at it. The only issue I see is that we may need to tweak the branch-api to allow for the branch jobs to be a non-job type (i.e. computed folder)
It sounds like you will need to implement a BranchProjectFactory (example: WorkflowBranchProjectFactory) that is a factory for a ComputedFolder (example: WorkflowMultiBranchProject).
Good luck!
I have a repository which contains a badge from Travis-CI. This badge is included in the Readme.md with the following link, as suggested by Travis-CI documentation:
[](https://travis-ci.org/nikicc/orange3-text)
However, now everyone that forks my repo will got the links to my Travis-CI badge, since it is hardcoded along with my username. I would like to achieve that all forks automatically have the links to theirs badges, not mine. Is it possible to somehow bypass this by using some variable for the username of the repository inside Readme.md files on Github? Is there any nice solution for this?
There is an alternative way to make it work:
Github: Can I see the number of downloads for a repo?
(https://github.com/andry81-devops/github-accum-stats)
It can be adopted the same way for an external service or site with data. All you need is to write a shell or any other script and call it from the github workflow action (.github/workflows/blabla.yml file).
The only thing can be a problem here is the GitHub workflow pipline call frequency, which might has a limit something about 1 call per 1 hour or 15 minutes (I didn't test it).
The idea is the same - store the status in a separate repository and does update it from a GitHub workflow action. Later you can use another action to rewrite the statistic repository below the head commit to cut off the history of changes if not need it.