Is there any possibility how to comment a deployed build on heroku?
For example, I want to put a simple comment before releasing a new version to the production, like version x.y.z. - stable
So if the build from a stage pipeline somehow failed, i know where to return...
I hope there is such an addon, but I guess this should be somehow part of heroku, shouldn't it?
Thanks!
You can leave an annotated tag in your Git repo.
Related
I'm beginning to understand how Heroku works, but haven't yet used a pipeline. I have an app I'm working on that is near its first production version. I'd like to begin using pipelines.
But I don't understand how to begin. What do I need to do to make a copy of the current app and have that copy be in the development stage and make another copy for the staging stage? Do I fork my git repository twice and add each one?
I'm trying to take this one step at a time. I don't need GitHub integration yet. This is a small project and will not have any pull requests for quite some time, if ever. I'm only interested in the ability to develop, stage and release in the three stages offered by Heroku.
While pipelines do use multiple apps, they should use the same git repository with different remotes. Heroku's help page helped me understand that the process is to link the repository to each app different remote names and then push to the remote that I'm currently working on.
Im using Heroku CI to run tests in Heroku Pipeline. I would like to add CI status as badge in the README.md file at Github, for master branch.
But so far, I have not found out-of-box solution on this request. Any tip on workarounds to get this work without building the ci-badge solution myself?
Few inspirations I have found:
https://github.com/heroku/heroku-ci: (see the status badge on top of README.md. However, image URL is specifically searching for pipelines for the Heroku CI application, and doesnt work with other applications)
https://github.com/pussinboots/heroku-badge: displays deploy badges, which is not important for me. Also, this repo/app doesn't seem to be maintained anymore (last commit 2 years ago)
I agree that a good Heroku CI badge generator is lacking! Heroku is still running one here, but the linked GitHub repo is unfortunately 404 (and, as you noted, that generator doesn't seem to work with pipelines other than Heroku's own, which makes it not that useful).
In any and all cases, inspired by your question, I went ahead and created a Heroku CI badge app that you can deploy to your Heroku account! Please find it here.
Feel free to open issues / fork it if you want to change anything.
Cheers
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.
What I want to do:
I want to set up Continuous Integration with Team City for a project that's hosted on GitHub.
What's Currently Working
I'm properly connected to GitHub. Commits, pushing, etc etc all seem to be fine.
TeamCity is set up and I can kick off a build which will run and run my unit tests, but...
What's Not Working
When I do a TeamCity build, it looks like it's pulling down code from GitHub before doing the build or running unit tests. I want to trigger a TC build when I do a commit, before it does the push to GitHub. I don't really want it to pull any code out of GitHub before running the TC build. This doesn't seem to be working at all.
I've set up a BuildTrigger which is a VCS Trigger. I've checked the box that says Trigger a Build on Each Check-in. I added a rule to the BuildTrigger with the VCS (Github) source and my username.
When I do a commit, I don't notice TC doing anything. When I then push the commit to GitHub, TC doesn't do anything either. I see no builds queuing or anything like that.
Any clues on what I'm doing incorrectly?
Thanks!
Have you looked at TeamCity's pre-tested commit feature? It doesn't work exactly as you described you would like your workflow to operate, but it might be useful. I've used it with Subversion in the past and it works pretty well, I haven't used it with Git but JetBrains state it also works with Git.
However, the most common workflow for Git is to create feature/bugfix branches for everything you do, which allows you to commit and push freely, and merge to master when you are ready. GitHub makes the merge (and optional code review) step painless and TeamCity has built-in support to automatically build branches, see the TeamCity documentation on feature branches for specific details it provides.
I'm attempting to get jenkins to build a project, but it seems to want to do a fresh clone everytime for some reason. I get this error:
none: ssh://hg#bitbucket.org/marc/repo/
which looks different than ssh://hg#bitbucket.org/marc/repo/
so falling back to fresh clone rather than incremental update
Is there something that would cause this? The two mentioned URLs are the same.
Turns out that with the debug option set to true (in the global jenkins settings for Mercurial) it will not update (but will clone), so this is a bug in the mercurial plugin for jenkins, but with a workaround that you can disable debug.
Your build probably changes some files/directories in the original structure of your local copy. Jenkins detects it and restarts fresh to be clean.
regards
didier