The build script is doing this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | tr “{” “\n” | grep “"$tag"” | tr “,” “\n” | grep “"id"” | sed ‘s/“id”: "([0-9]+)./\1/g’
That’s grabbing a bunch of JSON and then “parsing” it by turning each object into a line, and then finding lines which match the release tag treated as a regexp, and then finds the JIRA id for the release in a similar way.
Release 2.5.3 has a JIRA ID of 20515 which just happens to match the regular expression 2.5.5 So it produces 2 IDs which then breaks everything.
grep -F stops treating it as a regular expression and just matches the string. That’s still not parsing the JSON properly and it could still break quite easily, but it stops this particular problem.
···
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
Yuck.
The jq command-line tool can handle this: http://stedolan.github.io/jq
If I understand correctly, a 2.5.5 tag should yield 20833. This could be done using jq like this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | jq ‘. | select(.name==“2.5.5”).id’
Where . grabs all the objects and pipes them to a property filter grabbing the id of any that match.
···
On Tue, Feb 17, 2015 at 5:46 PM, Kevin Smith <ksmith@anonymised.com> wrote:
The build script is doing this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | tr “{” “\n” | grep “"$tag"” | tr “,” “\n” | grep “"id"” | sed ‘s/“id”: "([0-9]+)./\1/g’
That’s grabbing a bunch of JSON and then “parsing” it by turning each object into a line, and then finding lines which match the release tag treated as a regexp, and then finds the JIRA id for the release in a similar way.
Release 2.5.3 has a JIRA ID of 20515 which just happens to match the regular expression 2.5.5 So it produces 2 IDs which then breaks everything.
grep -F stops treating it as a regular expression and just matches the string. That’s still not parsing the JSON properly and it could still break quite easily, but it stops this particular problem.
–
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436
@boundlessgeo
Thanks Ian,
Putting jq in ‘raw’ mode and putting in the variables gives
curl -s -G $JIRA_REST/project/$JIRA_PROJ/versions | jq -r “. | select(.name=="$tag").id”
···
which seems to work perfectly.
I was able to install jq on ares so this modification should work there. Are there any other places these scripts get run that would make depending on jq a problem?
On 18 February 2015 at 08:15, Ian Schneider <ischneider@anonymised.com> wrote:
Yuck.
The jq command-line tool can handle this: http://stedolan.github.io/jq
If I understand correctly, a 2.5.5 tag should yield 20833. This could be done using jq like this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | jq ‘. | select(.name==“2.5.5”).id’
Where . grabs all the objects and pipes them to a property filter grabbing the id of any that match.
–
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
On Tue, Feb 17, 2015 at 5:46 PM, Kevin Smith <ksmith@anonymised.com> wrote:
The build script is doing this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | tr “{” “\n” | grep “"$tag"” | tr “,” “\n” | grep “"id"” | sed ‘s/“id”: "([0-9]+)./\1/g’
That’s grabbing a bunch of JSON and then “parsing” it by turning each object into a line, and then finding lines which match the release tag treated as a regexp, and then finds the JIRA id for the release in a similar way.
Release 2.5.3 has a JIRA ID of 20515 which just happens to match the regular expression 2.5.5 So it produces 2 IDs which then breaks everything.
grep -F stops treating it as a regular expression and just matches the string. That’s still not parsing the JSON properly and it could still break quite easily, but it stops this particular problem.
–
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436
@boundlessgeo
Good point that the portability may be an issue though I guess there is an implicit dependency on curl. I don’t know of any myself.
···
On Wed, Feb 18, 2015 at 3:37 PM, Kevin Smith <ksmith@anonymised.com> wrote:
Thanks Ian,
Putting jq in ‘raw’ mode and putting in the variables gives
curl -s -G $JIRA_REST/project/$JIRA_PROJ/versions | jq -r “. | select(.name=="$tag").id”
–
which seems to work perfectly.
I was able to install jq on ares so this modification should work there. Are there any other places these scripts get run that would make depending on jq a problem?
On 18 February 2015 at 08:15, Ian Schneider <ischneider@anonymised.com> wrote:
Yuck.
The jq command-line tool can handle this: http://stedolan.github.io/jq
If I understand correctly, a 2.5.5 tag should yield 20833. This could be done using jq like this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | jq ‘. | select(.name==“2.5.5”).id’
Where . grabs all the objects and pipes them to a property filter grabbing the id of any that match.
–
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
On Tue, Feb 17, 2015 at 5:46 PM, Kevin Smith <ksmith@anonymised.com> wrote:
The build script is doing this:
curl -s -G http://jira.codehaus.org/rest/api/latest/project/GEOS/versions | tr “{” “\n” | grep “"$tag"” | tr “,” “\n” | grep “"id"” | sed ‘s/“id”: "([0-9]+)./\1/g’
That’s grabbing a bunch of JSON and then “parsing” it by turning each object into a line, and then finding lines which match the release tag treated as a regexp, and then finds the JIRA id for the release in a similar way.
Release 2.5.3 has a JIRA ID of 20515 which just happens to match the regular expression 2.5.5 So it produces 2 IDs which then breaks everything.
grep -F stops treating it as a regular expression and just matches the string. That’s still not parsing the JSON properly and it could still break quite easily, but it stops this particular problem.
–
Kevin Smith
Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436
@boundlessgeo
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com…3839…
1-877-673-6436
@boundlessgeo