I'm very new to GitHub Actions/CI/CD, and I want to know whether it is possible to automate the following scenario:
I have a local script that makes use of some APIs to download some files onto my local machine. My current status is that: I have to run the script every day to check whether the content of these files is updated or not. If some of those files got updated then I need to add those changes into a new branch and push it to a repository as a PR.
My trying: My idea is that since it's possible to compare the hash of the downloaded files to know whether any of those got updated. The next thing to do is to make this into an event to trigger some action?
If it's possible could you share some resources/tutorials about how to do it?
I tested something similar on GitHub to understand how the CI/CD GitHub actions works.
the script is based on an SQLite DataBase which is updated automatically each time (automatic git push). And it uses Github Secrets to store encrypted Tokens/Passwords.
You can find my scheduler in the follow link: https://github.com/noweh/project-marvel-memories/blob/master/.github/workflows/run-schedule.yml.
you can find more information directly in the github documentation.
Here for the Github actions: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows.
And here for the Github encrypted secrets: https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-an-environment
Related
I built a website on github and would like to protect it from someone copying my repository and running the same website (either online or offline for themselves).
The website is fairly basic and builds on github action, which excute on schedule a Rmarkdown file that produces (updates) the index.html file. I want to avoid people being able to copy and freely execute that Rmarkdown file. I wonder if I could encrypt that specific file, and simply use a secret key with github actions to decrypt it when updating the website. Is this possible and would it be a good solution?
I also thought about having a private repository with my Rmarkdown file and simply push the html file to the public repository via github action, the problem is the github action takes a while to execute and I would quickly run out of the computation time (2000-3000 mins/month) offered by github.
I also thought about having a private repository with my Rmarkdown file and simply push the html file to the public repository via github action
That would have been the first approach, but since the RMarkdown process consumes to much tasks, it needs to be executed elsewhere.
Since other online free plans (like RStudio Cloud) are also limited in their project hours per month, another approach would be to call your own managed server (for instance, a Google Cloud compute engine, or Digital Ocean Droplet) where:
the RMarkdown file would reside (meaning, it would not be in the GitHub repository at all: no need to obfuscate/encrypt anything)
the process can take place
the generated index.html can uploaded back to your repository, and the rest of your GitHub action can publish the pages.
This is for a repository containing a library. The library version number is incremented (manually) each time a Merge Request to master is accepted.
However, if I want to access a file from version X.Y.Z, I have to look for the commit that incremented the version number to X.Y.Z, get its date, and then look in the history of the file for the version at that date.
I would like to create a tag per version, automatically when the Merge Request to master is created. Is this possible?
I hoped it would be possible with the new GitLab slash commands, but there currently is not support for tags.
Is there any other possibility than using web hooks?
While facing the same challenge, I stumbled upon this suggestion on GitLab's former issue tracker on GitHub1:
“You can write up a script to use GitLab API to accept a merge request, get the commit of the merge and then tag that commit.” --MadhavGitlab
(just to mention that — for me that's not sufficient)
1 EDIT:
Looks like all issues have been purged from the GitHub mirror, so this link does no longer work, but luckily the relevant quote persists right here.
I first tried to do it the gitlab way, by creating a .gitlab-ci.yml file in the project top-level directory. That file can contain the commands creating the version tag. The user executing the script has to have enough permission to push to the git project, and be configured with authoring information.
I finally did it on a Jenkins server, where I created a job that is invoked when commits are pushed into a specific branch. The tag can be created in the execute shell commands.
There is an open source project (https://github.com/firebase/firebase-jobdispatcher-android), which I would like to get built using travis/circleci or another cloud ci. However, those CI's don't allow you to get to repos that are not yours.
I didn't try, but I have a hunch that I won't be able to get a webhook setup as well to get notified when those repos 'master' branch is updated.
Why not fork ? Because then I somehow need to manually\use cron server to get my forked repo updated! It loses the point of having open source repo builds...
Why do I want to build it continually? Because they do not upload their .aar output to mavencetral or jcenter and I don't want to put the .aars in my project and get it updated all the time - bloats the repo...
In any case, I don't get it - there's an open source project, the repo exists and open to everyone, pulling the data and getting webhooks doesn't compromise that repo in any way why isn't this possible ????
If I'm mistaken and web hook is possible, how can I set up a build that will end up in uploading to mavencentral (probably gradle plugin, I have an account and be happy to have a public copy there)?
(I thought of micro service, free of course of some kind + docker based ci which I can pull and build whatever, I don't mind if a build will take time).
I already have 2 automatic builds on hub.docker with Dockerfiles hosted on github. They are working great. My problem is now I want to use a Dockerfile in an github repository which is not my own but I am admin and member and have full access to. I can see several other repositories on the hub.docker page when I try to create a new automatic build. They are very similar to the one I want to use but the one I want to use is not listed there, although I have full access to it. I ready through do documentation from hub.docker and I also logged in and out. Further more I also delinked my github account and relinked it. (with write persissions). So my question is how can I make the other repository visible on hub.docker in order to create an automatic build?
The project that I am working on is a jQuery plugin. I have managed to get Travis CI to build a test project using Gulp/NodeJS successfully. Now I am trying to work out what workflow to use to bump the version number.
In TeamCity and MyGet there is a setting in the CI server to form a version number pattern that auto increments on each build, which can be used by the build script to update versions in the deployment files and to label the Git repo. However, in the free version of Travis CI, there doesn't seem to be an option for versioning at all.
I have read several articles on continuous deployment with Travis CI, here, here, and here, but none of them even broach the topic of versioning. Obviously, the version needs to be changed for the release. So what am I missing here?
Another problem I noted when going through the documentation is that it mentioned that Travis CI is not able to update the GitHub repository. Doesn't that basically mean it won't be able to create a Git tag?
If there is no way to version from Travis CI, then what is the typical workflow for the release process for such a plugin? Is the versioning always done manually? If so, how could there be "continuous deployment"?
Before it starts running the instructions in your .travis.yml file, Travis will set a bunch of environment variables (in the VM that is building your project) with various bits of information about your build, such as what branch is being built and so on.
You probably want one of these:
TRAVIS_BUILD_NUMBER: The number of the current build (for example, “4”).
TRAVIS_JOB_NUMBER: The number of the current job (for example, “4.1”).
But it's going to be very difficult to do anything sensible if you don't have control of the repository, because you'll need to upload a .travis.yml file into the root of your source code folder, otherwise Travis won't know what to do.
Use bumped for release versioning. When you're satisfied with the changes in master, run:
bumped release <major|minor|patch>
After you push the changes, either directly or through a release PR, you can check for the presence of new tags in Travis CI and publish the package to the registry automatically.
If you consider that every PR must end up to your enduser without thinking of the impact of such changes, then your version numbers have no meaning.
You don't give your user a way to know if it is a major change that break compatibility or a bug fix. You don't allow him to get update without worrying about backward compatibility.
Currently, the commit id is your version number.
If you want to give meaning to your version numbers then you have to think of the impact of your pull requests on the enduser (http://semver.org/). You have to choose a version number for a specific PR or a group of PR.
So basically, since you have to 'think' of a certain version number for a specific version that you want to deliver, you can't automate this process.
Release/tag creation is the way to go : )
You can accomplish this by setting up a script that would create a ~/.netrc file to access the repository. In this file you can specify something like:
machine https://github.com/xxx/yyy.git
login <blah>
And instead of putting in your credentials, you can pass an github access token. You can use the travis encrypt to register it in the .travis.yml file, and export the variable for your script's use. From there in your script, you can issue regular git commands such as:
git add <some file>
git commit -m "This is $TRAVIS_BUILD_NUMBER"
git push origin <branch>