--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hey,
There have been couple of posts[1][2] on Github PR integration in GoCD. I came up with a workflow and would love to hear what you guys think about it.
Ok Aravind's reply is saying the same thing as mine, only his is better, so you can ignore mine ;) Wish there was a merge conflict feature for emails :P
--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PRs (pull requests) are somewhat a black sheep when it comes to CD pipelines since most developers think of them as working drafts and not meant to be deployed anywhere until they are merged to master (although nothing should prevent one from doing this). Basically, what runs as part of a PR should only be a subset of the whole pipeline, the CI part of it.Also, a PR might change the code in such was that the pipeline no longer "fits". For example, say that I have a PR that adds support for Python 3, well, I would like the pipeline to run Python 3 tests. But then if I add a Python 3 job to my pipeline, now my other PRs will break because they don't have Python 3 support yet. It's a chicken and egg problem.This is also why I believe that the CI part of the pipelines should be defined in the code repository project itself. Travis CI did this beautifully by having on-demand, throw-away pipelines (yes, they are not really "pipelines" per se). The repo is cloned, the "travis.yml" file is found and created accordingly then the code it pushed through it. Once done, the pipeline is destroyed (although the visualization of the pipeline is archived for future reference), artifacts are saved and that's where the CD cycle ends for a PR, usually. But if you wanted to deploy the PR for some reason (to another testing environment) then the build artifact of the PR is used as the material to the next pipeline.
When the PR gets merged to master eventually, this is when the full CD pipeline should run so it eventually ends up to production if all tests passed.2015-02-02 10:47 GMT-08:00 Aravind SV <arv...@thoughtworks.com>:On Mon, Feb 2, 2015 at 9:20 AM, Ashwanth Kumar <ashwan...@googlemail.com> wrote:Hey,
There have been couple of posts[1][2] on Github PR integration in GoCD. I came up with a workflow and would love to hear what you guys think about it.Nice! I like it.You might not need the build task, actually. The SCM endpoint was accepted just a couple of days ago. Its documentation is in progress. What it provides is a "Checkout" message, which is used to tell the agent and server to checkout, using the plugin, to a specific revision of the material. I feel this removes the need for a task, if you want. Assuming, we can somehow differentiate between agent-side plugin and server-side plugin usage.When Srinivas and I talked about GitHub a couple of days ago, and an approach like this, the small bump we hit was that multiple PRs, seen by this plugin, will be bunched together and run. That's the wrong behavior, isn't it? This needs a bit of a change in Go's scheduling, right?I mean:PR 1 is created or changedGo starts building itPR 2 is created or changedPR 3 is created or changedGo finishes building PR1Next build scheduled will be with both PR 2 and PR 3.This is because, in Go, multiple "commits" which show up while building can be bunched together. This is true of SCM commits, but is not true for PRs, since PR2 and PR3 are not necessarily related. PRs are not really commit, but whole branches, which is why we run up against this.--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Alex
Thanks for pointing me to SCP Endpoint. I read the documentation and was wondering, if there's a way to return a batch of latest revisions may be then we could trigger the pipeline (multiple times) with the corresponding checkout revision. In this case, it would one per PR. I guess this is what you mean by changes in Go's scheduling.Or like the way Srinivas put in the #298 if we can create pipeline clones on the fly that would also do the trick.
--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
- So I see you clone ’’/head", but do you end up merging it with the target branch? The merged version is what I'm really interested in since this is the whole point of testing a pull request: to make sure that once merged, everything is still going to work. Testing just the head of the branch doesn't provide much insight on whether the tests will properly run. You can also use the "/merge" branch which is only available when there are no merge conflicts (see my previous message in this thread).
- Do you inject useful environment variables of the PR payload? such as PR_ID=3; PR_BRANCH="myfeature"; TARGET_BRANCH="master"; PR_URL="https://...", etc. (the target branch may only be available via the Github hook payload). But these environment variables would be very useful for scripts in the pipeline to take extra actions based on the information from the PR.
- I see you have github.com hardcoded, but my company uses Github Enterprise only accessible from within our VPN. It would be nice if it could leverage any Github instances, not just the public github.
- Does it support Github webhooks or polling only? (I know Github has a builtin GoCD webhook, should we leverage this?)
On Sat, Feb 21, 2015 at 4:16 AM, Alexandre Conrad <alexandr...@gmail.com> wrote:- So I see you clone ’’/head", but do you end up merging it with the target branch? The merged version is what I'm really interested in since this is the whole point of testing a pull request: to make sure that once merged, everything is still going to work. Testing just the head of the branch doesn't provide much insight on whether the tests will properly run. You can also use the "/merge" branch which is only available when there are no merge conflicts (see my previous message in this thread).I currently only checkout the revision that's the latest on the PR. I wasn't sure on how to handle the cases when /merge branch isn't available? What do you think is the right way to do it?
- Do you inject useful environment variables of the PR payload? such as PR_ID=3; PR_BRANCH="myfeature"; TARGET_BRANCH="master"; PR_URL="https://...", etc. (the target branch may only be available via the Github hook payload). But these environment variables would be very useful for scripts in the pipeline to take extra actions based on the information from the PR.I've only the PR_ID, I'll add the PR_BRANCH, TARGET_BRANCH and URL. Anything else to add?
- Does it support Github webhooks or polling only? (I know Github has a builtin GoCD webhook, should we leverage this?)Currently it polls periodically (runs as part of Go's MDU). I don't have much insights on how Github's webhook work. Also, I'm not sure if that can be handled in the SCM endpoint.
I would suggest moving the "core git" functionality out into a common module which everyone (github, bitbucket etc.)I am working on that module. It will support both JGit & git command-line client hopefully.What do you guys think?
@Ashwanth - I have written post-commit hook support for scm end-point. So you can turn off polling & add web hook on GitHub when a PR is added/updated/closed. The UI bit is ready to be merged. Will be in soon.
On Fri, Feb 27, 2015 at 11:28 AM, srinivas upadhya <srinivas...@gmail.com> wrote:I would suggest moving the "core git" functionality out into a common module which everyone (github, bitbucket etc.)I am working on that module. It will support both JGit & git command-line client hopefully.What do you guys think?By that you mean, one SCM Plugin that supports regular Git and PR (from hosted services). Correct? If yes, I'm up for it.
@Ashwanth - I have written post-commit hook support for scm end-point. So you can turn off polling & add web hook on GitHub when a PR is added/updated/closed. The UI bit is ready to be merged. Will be in soon.Sweet, I'll make the changes accordingly.
Quick question - When is the Release 15.1 happening?
--
You received this message because you are subscribed to a topic in the Google Groups "go-cd-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/go-cd-dev/Rt_Y5G2VkOc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to go-cd-dev+...@googlegroups.com.
So the SCM's latestRevision and latestRevisionSince are called as part of the Go's MDU process. The plugin takes 1 new PR at a time and schedules it. To answer your question - we schedule multiple PRs sequentially.Ref - This line checks for any new PRs from the given current state of PRs (activePullRequests).- If your build Pipeline has only 1 stage you can't run them in parallel, Go's design is that no 2 versions of the pipeline#stage combination runs in parallel.- One SCM Plugin can be used in multiple Pipelines, so my guess is MDU check is independent of whether a build is happening or not. If the plugin should return valid revisions on latestRevision or latestRevisionSince messages, my understanding is they would be scheduled automatically by Go.GoCD's core team guys can much provide better insight into these questions.
Great effort...
Has anyone by any chance looked into integrating stash into a similar plugin (based of @srinivas upadhya's git-cmd module maybe?)...
--
You received this message because you are subscribed to the Google Groups "go-cd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd-dev+...@googlegroups.com.