strider
strider copied to clipboard
Strider-CD
Deploy only when create a new release/tag
i would like to know if is possible configure strider to deploy using github tags instead of using directly branch's.
@fernandoneto sounds like a nice idea, although not currently supported. You might be able to write a bash script and use it in the custom scripts plugin..
@knownasilya thank you for your fast answer. about the bash script idea i cant get your train of thought. can you please be more verbose? :)
You could use something like this in a bash if statement in the strider-custom's (installed by default, enable it in the branches plugins) deploy section.
@knownasilya in fact i think i express myself wrong. what i really want is after create a new tag based in a branch, strider is able to deploy it.
so my question is : If i create a tag in Github, strider will be notify and run based in that tag?
let me give you an example:
You and your team work in a branch for some time, every time you push commits strider run tests. So you want to send the code to productin servers. You create a tag based in that branch, and strider will deploy the code. maybe this can be possible using webwooks i think ???
hope you understand my idea :)
Ah, so you're wondering if pushing a tag will kick off a job in strider? Not sure..
But using that SO answer you can increment a version somewhere and tag it, and just check if that commit has a tag. It's a workaround, but it's better then nothing.
Yep thats it. maybe a plugin that give this options would be very usefull don't you think?
Sounds like a feature for strider-github, strider-bitbucket and strider-gitlab
https://developer.github.com/webhooks/#events https://github.com/Strider-CD/strider-github/blob/master/lib/api.js#L42 https://github.com/Strider-CD/strider-github/blob/master/lib/webhooks.js#L227
Add the create and release events to handle tags and releases.
The only issue is how do you decide which branch to trigger? Maybe postfix the tags with the branch name (also have option to configure it)?
- master: v1.0.0
- develop: v1.0.0-develop
- feature-a: v1.0.0-feature-a
Feel free to play around with some ideas, and submit a PR to try it out.
I can confirm new tags kick off a job in Strider, at least with Github and Bitbucket. I'm not sure if it is at the provider's discretion whether or not to push that info in a webhook.
I believe only Github starts jobs for Pull Requests, but I don't think so for Bitbucket
Yep, I just tested it a couple times even. They don't come back with anything in the 'branch' column though. Not sure about what the Strider metadata contains either.
Interesting, I think it's registered as a commit, because that's the default.
So yeah, builds no longer make sense to be focused on a branch so tightly.
@knownasilya i already have strider start from release new tags. my proble now is the same as @bitwit . i can get any information in branch column.
Could you tell me the file where i found that confguration?
@fernandoneto tags are not placed on branches, so you can't have branch info. This is why fundamentally strider needs to be reworked to have builds not heavily tied to branches.
Hey @knownasilya !
@fernandoneto is my co-worker/mate!! :) I asked him to place and follow up this discussion so we can fire releases to our production servers directly from GitHub releases instead of branch updates. Thanks for bringing up discussion about this so far!
github releases might be tied to branches
GitHub releases are created on top of git tags, which means that you couldn't have a GitHub release without having a git tag.
Since Strider is catching up git tags as branches, could the configuration be as simple as creating settings for refs/tags/* ?
So that most likely will work, but the problem is that strider expects a certain output to keep the reference of your build, and this output happens to be the branch information. For tags to be supported properly, strider needs some changes. Currently it will probably hit the * "branch" when you use a tag.
but the problem is that strider expects a certain output to keep the reference of your build, and this output happens to be the branch information.
What kind of branch information?
Just tested a git checkout directly from refs/tags/... and git sees it as detached HEAD. If Strider is okay with that, we just need to access to some kind of build history to avoid Strider to build already built tags (in case we mess up with something).
EDIT: PoC for my last statement:
Basically Strider needs something to associate the tag to a build, which is what is done with branches, it's associated by the branch name. Since tags are different every time, we'd need a tag pattern, like a regex or something.
Something like {semver}-production, where v1.2.3-production would trigger that build.
Well, I spent a couple of minutes trying to make a semver-compatible regexp (already with version descriptors checking) in case you need it.
^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}(?:-[a-z0-9\-]*)?$
some acceptance testing
For my understanding perspective, and correct me if I'm wrong, you're saying that current working Strider version can do the job if we place some pattern to detect a sort of tags? Like refs/tags/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}-production?
It will need some tweaking to match up the tag with the build (the regexp, and look at the right data), since the response from github is different for tags.
Could you please assign me for this? This weekend i will review entire Strider and strider-github code and PR this feature.
@cusspvz feel free to submit a PR. We can iterate till it looks good.
You might be looking at strider-git instead, since it's at the tag level.
This is currently at my urgent TODOs since we have it as a dependency. Maybe tomorrow I will dig up on this.
I've read entire strider-github repo already, since there are a couple of ways to apply this, i will get into this afternoon because I need to discover differences between payloads first.
