I have a little-to-none understanding of what travis-ci is. All I know ( and I could be wrong ) is that, it is where a github code is hosted. This code has a test written in Unit Tests, and Travis is a way to automatically test whenever a new commit is pushed to github. As I said, I could be totally wrong. Wikipedia article didn't help me understand this.
But, in the case that it is a test automation software, then how do I set up a simple application? I have a github account, and I know the first step is to register in travis, connect a github account and place a travis.yml file but what is next?
Any help would be appreciated.
What Travis CI does is connects to your GitHub repository to run you code's tests (Scripts that write to confirm that your code is working) on every commit you make on GitHub. It also runs on pull requests, which makes it great for checking if a pull request breaks anything. You can get started by going to the Travis CI and hitting sign in on the top right corner. You'll sign in with your GitHub account, and on the profile page you can turn on the repositories that you want Travis CI to test. Next, you'll need to create a .travis.yml in the repositories you want to test. You didn't specify what language you to would like to use so I'll refer you to the Travis CI getting started page which has examples in every language that Travis CI supports.
If you want to read up more I reccomend taking a look at the Travis CI docs.
Related
I have a couple of questions about devops/docker/github actions.
I'm pretty new to all of this, seen some full implemented projects but I'm missing some "parts".
I'm trying to set up a "complete project" myself, just for exercise/training and getting familiar with everything.
For now, I have 3 branches: dev, uat and master.
I work on dev (it's the default branch). I create a local branch of the dev branch and push my local changes to that branch.
Every time I finish a job (let's say user login functionality), I push this to uat.
Some customers get access to the uat server and are able to test these new functionalities. After they accepted the changes, everything from uat goes to master (which is the live server).
So far so good I guess, and if I miss something or there are things I can do better please let me know!
What my questions are:
If I push changes to the dev branch, it should automatically test these changes before I'm able to open a pr to the dev branch, is this possible with Github Actions? Or do I interpret the things I read on the internet wrong?
When things are tested during this push, do I have to spin up a Docker container? Or do I test these things on the ubuntu VM given by Github Actions? What is the best practice?
I know there is the possibility to do both, but what is considered best practice?
Does someone has an example? Or a tutorial/blog about this? I'm trying to connect the dots but I'm a little stuck...
Cheers and many thanks for the help!
1 - This video explains it simple and quick
2 - If you deploy it using docker, test it using docker
3 - see 1
Edit:
This other video is also a really nice tutorial that uses docker.
I have a Jenkins server (2.249) setup and I have connected my GitHub account and tested the connection and it works fine, but for a normal pipeline job where you enter the GitHub repo url, Jenkins seems to add an extra slash at the end? So I can't get my normal pipeline job to build on a push event, I've checked the logs and it says:
skipped [repo-name] because it doesn't have a matching repository.
So I've starting to think its because Jenkins is adding an extra slash at the end of my repo url? The webhook on the GitHub side works as it gives back a green tick and it works on another multibranch job for push events, just not the normal pipeline jobs.
Don't know if the problem is still on after more than one year but because I've just faced the same issue, here is an answer that help me to understand : https://serverfault.com/a/884717
Just to resume the answer : you have to complete the git part (scm) of your Project Configuration :
For my part: as the project is a private one, in an organisation that I can't update to add a personal token (as I'm not the owner of the resource - organisation), I choose to use the git+ssh url with a ssh key access to this repo. The next trick for github is to add the github's IPs to the jenkins user know_hosts file !
The reason behind the need to add twice the repository url is obscure. But I could only see that in https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubRepositoryNameContributor.java#L113 the method parseAssociatedNames will try to get the Jenkins'job associated names from :
com.cloudbees.jenkins.GitHubRepositoryNameContributor$FromSCM
com.cloudbees.jenkins.GitHubTrigger$GitHubRepositoryNameContributorImpl
org.jenkinsci.plugins.github_branch_source.GitHubSCMSourceRepositoryNameContributor
I think the third one is for multibranch pipelines. I don't really know for the second but indeed the first one is fromSCM configuration !
Just to quote as an example one can submit a remote-run with some tool like TeamCity (similar to Jenkins) where it will apply delta/patch on what user is trying to commit & produces result whether changes is good from set-of configured checks for that project.
With Github & Jenkins, can such validation be achieved with any plugins out there?, which will avoid breaking a build?
I know with pull-request & status check one can achieve similar end-result. But without commit/push to remote repo of Git - is there a way Jenkins can handle this validation & produce initial result ??
It isn't possible to have GitHub perform checks on data it doesn't have, so if you don't push the data to the remote server, GitHub won't know anything about it and therefore will do nothing.
Jenkins does have a REST API that you could use to do this, provided you equipped each developer with appropriate credentials. However, this is not a common situation and wouldn't be a recommended configuration.
You'd be better off with a script in the repository that users could install as a hook or invoke from a hook that would perform the testing you want. If your CI jobs run a script in your repository, then sharing code between them should be easy.
Note that you shouldn't mandate pre-commit hooks, since they can interfere with advanced users (who may make intentionally incomplete temporary commits) and they can be disabled by users. Any sort of required checks should be done as part of CI, where policy can be enforced appropriately.
Bamboo and bitbucket are two pieces from the same vendor and there should be no problem integrating those two with each other, but I have a weird situation.
Here is what i get when trying to add bitbucket repo to my Bamboo.
See attached screenshot.
I'm pretty sure my repo is public and I use correct bitbucket user account name.
Thanks in advance.
I have installed BAMBOO to AWS using Java script provided by Atlassian
At the end it gave me a web UI links as on following screenshot .
It worked, however some functionality was blocked by XSRF (that is not enabled by default in Atlassian products).
Works fine when I use native Bamboo URL (HTTP and port 8085) instead on HTTPS.
Be careful with that... I just wasted about 2 days trying to fix something that didn't have to be fixed at all.
Have you linked your Bitbucket repo to Bamboo server. If not see this https://confluence.atlassian.com/bamboo/linking-to-another-application-360677713.html
May be this can help.
I have a Ruby/Rails project I inherited. It's a private github repo, and it's hooked up to CircleCI in the standard way: github won't allow a merge til the required CircleCI tests pass. That's fine, but when I create a pull request, I only get "ci/circleci — Waiting for status to be reported" and that never changes (I waited all weekend). I'm not sure where to look for log files, or what might be going wrong. I'm new to CircleCI. Any help? The last item I see in my circleci dashboard is months ago, so it's almost like it's not seeing the new pull request. But I can see github sending it and getting a 200 reply.
BTW, the circle.yml just sets the machine timezone, nothing else, nothing fancy.
You may need to configure the branch settings:
https://circleci.com/docs/2.0/workflows-waiting-status/