I'm wondering if there are any convenient ways to automate deployment of code to a live server in GO, either standard built-in methods, or otherwise.
I want something google app engine like, I just run the command and it uploads to the server and triggers a restart.
(Ultimately I want a git commit to trigger a rebuild and redeploy, but thats for down the track in the future)
I recommend Travis CI + Heroku.
You can deploy to heroku directly with just a git push, but I like to use Travis to build and run the tests before that.
There are some guides online but I'll try to go directly to the point:
What you will need?
Github account
Travis account (linked with github, free if open source)
Empty Heroku app (Free dyno works great)
Setup
In your github repo, create the following files:
.travis.yml (more info on the Travis CI documentation)
Procfile
.go-dir
After that go to your Travis account, add your repository and enabled the build for it.
Here is a sample minimal config file content (based on my app that I deploy to heroku):
.travis.yml
language: go
go:
- tip
deploy:
provider: heroku
buildpack: https://github.com/kr/heroku-buildpack-go.git
api_key:
secure: <your heroku api key encripted with travis encrypt>
on: master
Procfile
worker: your-app-binary
.go-dir
your-app-binary
Procfile and .go-dir are heroku configs so it can vary if you are deploying a web app, you can read more at the heroku documentation
One important and easily missed point is the build pack, without it the deploy will not work.
Read the Travis docs to see how to encrypt the heroku key
How it works?
Basically, every push to your repository will trigger the Travis CI build, if it passes it will deploy the app to heroku, so you set this up once and build + deploy is just a push away ;)
Also Travis will build and updated the status of all Pull Requests to your repository automagically.
To see my config and build, please take a look at my Travis build and my repository with my working configs
Related
I'm having an issue where I can only deploy changes to heroku via a manual command.
I've already followed the guide and set up auto deployment through github https://devcenter.heroku.com/articles/github-integration but it seems like changes are not deployed to heroku unless I explicitly run git push heroku main
Is there anything I can do to check how to automate the push?
Automatic deploy with Heroku and Github is temporary stopped
https://dev.to/lukeecart/herokus-github-integration-has-been-stopped-a7c
Follow the news : https://status.heroku.com/
We have a application which is managed by third-party. They use Github to store source code. My company now use Gitlab for internal project. We setup Gitlab mirror to pull source code (incl branch: dev, stagging, master) from Github. It's working well now.
Now my manager want to setup Gitlab pipeline for automation process: build, test, deploy...I do it by commit .gitlab-ci.yml file to branch. But it's not good. After Gitlab pull code from Gitlab, it will overwrite my gitlab-ci file and remove it. So I must find another solution
Below is my idea now:
Create seperate project. It only contains gitlab-ci file
Detect changes on any branch in mirror repo
Trigger pipeline
Anyone has other idea for this case, please help me
P/S: third-party don't agree to add my gitlab-ci file into their repo in Github.
I'm trying to use GitHub to trigger on PR a GitLab pipeline.
Practically when a developer creates a PR in GitHub, his/her code get tested against a GitLab pipeline.
I'm trying to follow this user guide: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html
and we have a silver account, but it won't work. When creating the PR, the GitLab pipeline is not triggered.
Anyone with this kind of experience who can help?
Thanks
Joe
I've found the cause of the issue.
In order for GitHub to trigger GitLab as CD/CI mostly in PR request, you need to have a Silver/Premium account AND, very important, being the root owner.
Any other case, you won't be able to see github in the integration list on GitLab. People from gitlab had the brilliant idea to hide it instead of showing it disabled (which would had been a tip to understand that you needed an upgraded license)
In the video above it's not explained.
Firstly, you need to give us the content of your .gitlab-ci.yaml file. In your question you asked about GitHub but you're following Gitlab documentation which is completely different. Both are using git commands to commit and push repos but Github & Gitlab are different.
For Github pipelines, you need to create a repository, then you go to Actions. Github will propose you to configure a .github/workflows directory which contain a file.yaml. In this .yaml file you can code your pipelines. According to your project, Github will propose you several linux machines with the adequate configuration to run your files (If it's a Java Project --> you'll be proposed maven machines, Python --> Python Machines, React/Angular -> machines with npm installed, Docker, Kubernetes for deployments...) and you're limited to 4 private project as far as I know (check this last information).
For Gitlab you have two options, you can use preconfigured machines like github, and you call them by adding for example atag: npm in your .gitlab-ci.yaml file, to call a machine with npm installed, but you need to pay an amount of money. Or you can configure your own runners by following the Gitlab documentation with gitlab commands (which is the best option), but you'll need good machines and servers to run npm - mvn - python3 - ... commands
Of course, in your Gitlab repository, and finally to answer your question this an example, of .gitlab-ci.yaml file with two simple stages: build & test, the only statement specifies that these pipelines will run if there is a merge request ( I use the preconfigured machines of Gitlab as a sample here) More details on my python github project https://github.com/mehdimaaref7/Scrapping-Sentiment-Analysis and for gitlab https://docs.gitlab.com/runner/
stages:
- build
- test
build:
tags:
- shell
- linux
stage: build
script:
- echo "Building"
- mkdir build
- touch build/info.txt
artifacts:
paths:
- build/
only:
- merge_requests
test:
tags:
- shell
- linux
stage: test
script:
- echo "Testing"
- test -f "build/info.txt"
only:
- merge_requests
I'm setting up a project with Travis CI and SonarQube.com, everything goes smoothly when a pull request comes out of a branch from the repository but it is failing when Travis runs a build off a pull request from a forked repository.
A build out of a PR from the repository: https://travis-ci.org/PistachoSoft/dummy-calculator/builds/162905730
A build out of a PR from a forked repository: https://travis-ci.org/PistachoSoft/dummy-calculator/builds/162892678
The repository: https://github.com/PistachoSoft/dummy-calculator
As it can be seen in the build log this is the error:
You're not authorized to execute any SonarQube analysis. Please contact your SonarQube administrator.
Things I've tried out but didn't work out:
Updating the sonar token.
Using an encrypted token granted by another person from the organization.
Granting 'sonar-users' and 'Anyone' the 'Execute Analysis' permission on the SonarQube project.
What can I do to fix this?
First, I raise your attention on one important point: you should not run a "standard" SonarQube analysis on PR - otherwise your project on SonarQube.com will be "polluted" by intermediate analyses that have nothing to do with each other. Standard analyses must be executed only on the main development branch - which is usually the "master" branch. Please read the runSonarQubeAnalysis.sh file of our sample projects to see how to achieve that.
Now, why your attempt does not work? Simply because the SONAR_TOKEN environment variable (that you've set as "secure" in your YML file) will not be decoded by Travis when the PR is coming "from the outside world" (i.e when it's not a PR of your own). This is a security constraint to prevent anybody to fork your repo, update the YML file with a echo $SONAR_TOKEN, submit a PR and genlty wait that Travis executes it to unveil the secured environment variable.
Analyzing "external" PR is something that we'll soon be working on so that this is easy, straightforward and yet secured for OSS projects to benefit from this feature.
I'm trying to figure out how to create a task (custom-command, not ant/rake, etc) to perform a deployment of a git-repo to some server/target (in this case Heroku). If I were to do this manually, it's just git push heroku master.
I've created a basic pipeline/stage/job/task (custom-command, in this case a Python script), and single agent. The pipeline has a material (git repo, with a name). Inside the script, I'm printing out os.environ.items() - it has several variables, including the SHA of the latest commit - but no URL for the actual repository.
So how is the agent (or task) supposed to know what repository to deploy?
The pipeline knows the material name, and I've tried passing in an Environment Variable such as ${materialName} (which didn't work). I could hard-code a URL in the task, but that's not a real solution.
Thoughtworks:GO's documentation is shiny, but a bit sparse in the details. I'd have thought something this basic would be well documented, but if so, I haven't found it so far.
When a task runs on an agent, it clones the repository specified in the material (config). The .git/config wouldn't have remote Heroku url and as such git push heroku master wouldn't work.
You would need to add Heroku remote url before you can perform a deployment of your git-repo to Heroku.
git remote add heroku git#heroku.com:project.git
where project is the name of your Heroku project. This is required to be done only once unless you perform a clean working directory every time (in Stage Settings which removes all files/directories in the working directory on the agent, you can see this option from the UI as well: Admin -> Piplelines -> Stages -> Stage Settings Tab) in which case you may have to add the remote url via a task before you run the task to deploy.
Once you've done so, you should be able to use the heroku xxxx commands (assuming you have the Heroku Toolbelt installed on the agent machine you are using for deploying), and should be able to push to Heroku as usual via git push heroku master.