Quantcast

[Tiki-devel] release.php

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] release.php

Brendan Ferguson
So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.

Its mostly just a straightforward port, but there are a few differences.

The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.

A few other minor changes including:
Better error checking
Better error reporting
Better archive compression
.tar.gz and .tar.bz2 now preserve file permissions
Stripping of .gitignore (and similar files) was extended
OSX tested and ready

Anyone who would like to test please do. Be sure to run with —no-commit option :)

Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?

Brendan




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

luciash d' being

Hi Brendan,

thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.

It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?

Just my 2c.

luci

PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.



On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.

Its mostly just a straightforward port, but there are a few differences.

The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.

A few other minor changes including:
Better error checking
Better error reporting
Better archive compression
.tar.gz and .tar.bz2 now preserve file permissions
Stripping of .gitignore (and similar files) was extended
OSX tested and ready

Anyone who would like to test please do. Be sure to run with —no-commit option :)

Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?

Brendan





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

Jonny Bradley-4
Hi Brendan and all again

I already commented on the commit similarly to Luci's concern, but i guess if you do an export it should be clean, i would just feel more comfortable with using the ''actual'' tag just in case - we still have to do the composer setup after that so the difference in running time must be marginal i would have thought.

Anyway, it's wonderful that you're tackling these things and modernising these critical tools, thank you ever so much! :)

jonny




> On 19 May 2017, at 10:28, luciash <[hidden email]> wrote:
>
> Hi Brendan,
>
> thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.
>
> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>
> Just my 2c.
>
> luci
>
> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>
>
> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>
>> Its mostly just a straightforward port, but there are a few differences.
>>
>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>
>> A few other minor changes including:
>> Better error checking
>> Better error reporting
>> Better archive compression
>> .tar.gz and .tar.bz2 now preserve file permissions
>> Stripping of .gitignore (and similar files) was extended
>> OSX tested and ready
>>
>> Anyone who would like to test please do. Be sure to run with —no-commit option :)
>>
>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>
>> Brendan
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org!
>> http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> TikiWiki-devel mailing list
>>
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

Brendan Ferguson
In reply to this post by luciash d' being
Hi luci

I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.

Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):

Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.

It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.

I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow. 

Brendan



On May 19, 2017, at 5:28 AM, luciash <[hidden email]> wrote:

Hi Brendan,

thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.

It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?

Just my 2c.

luci

PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.



On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.

Its mostly just a straightforward port, but there are a few differences.

The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.

A few other minor changes including:
Better error checking
Better error reporting
Better archive compression
.tar.gz and .tar.bz2 now preserve file permissions
Stripping of .gitignore (and similar files) was extended
OSX tested and ready

Anyone who would like to test please do. Be sure to run with —no-commit option :)

Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?

Brendan





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

Cloutier, Philippe (DGARI-Consultant)
In reply to this post by Brendan Ferguson

Hi Brendan,

I never touched /bin but it has several Windows files here.

 

I guess the documentation of release.php –debug-packaging needs adjustment.

 

De : Brendan Ferguson [mailto:[hidden email]]
Envoyé : 18 mai 2017 23:57
À : Tiki developers <[hidden email]>
Objet : [Tiki-devel] release.php

 

So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.

 

Its mostly just a straightforward port, but there are a few differences.

 

The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.

 

A few other minor changes including:

Better error checking

Better error reporting

Better archive compression

.tar.gz and .tar.bz2 now preserve file permissions

Stripping of .gitignore (and similar files) was extended

OSX tested and ready

 

Anyone who would like to test please do. Be sure to run with —no-commit option :)

 

Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?


Brendan

 

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

Jonny Bradley-4
In reply to this post by Brendan Ferguson

Oops, replied to the other list about this, should be doing the proper discussion here - just wanted to add i think /bin should not ever be in the release packages, surely not something you want on a production server?

jb




> On 19 May 2017, at 14:33, Brendan Ferguson <[hidden email]> wrote:
>
> Hi luci
>
> I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.
>
> Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):
>
> Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.
>
> It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.
>
> I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.
>
> Brendan
>
>
>
>> On May 19, 2017, at 5:28 AM, luciash <[hidden email]> wrote:
>>
>> Hi Brendan,
>>
>> thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.
>>
>> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>>
>> Just my 2c.
>>
>> luci
>>
>> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>>
>>
>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>>
>>> Its mostly just a straightforward port, but there are a few differences.
>>>
>>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>>
>>> A few other minor changes including:
>>> Better error checking
>>> Better error reporting
>>> Better archive compression
>>> .tar.gz and .tar.bz2 now preserve file permissions
>>> Stripping of .gitignore (and similar files) was extended
>>> OSX tested and ready
>>>
>>> Anyone who would like to test please do. Be sure to run with —no-commit option :)
>>>
>>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>>
>>> Brendan
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites,
>>> Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>>
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

Brendan Ferguson
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

luciash d' being
Now I see there is also symlink to minifycss and minifyjs vendor_bundled
scripts in the bin/ on my svn repository copy.

Not sure when they are called...

luci


On 20.5.2017 20:41, Dr. Sassafras wrote:

> I think /bin in general is not included in release packages. A quick look at it reveals it might not even be needed any more. I will take another quick look and if there is no obvious reason why it should stay, will strip it from the production release packages.
>
> Brendan
>
>> On May 20, 2017, at 7:41 AM, Jonny Bradley <[hidden email]> wrote:
>>
>>
>> Oops, replied to the other list about this, should be doing the proper discussion here - just wanted to add i think /bin should not ever be in the release packages, surely not something you want on a production server?
>>
>> jb
>>
>>
>>
>>
>>> On 19 May 2017, at 14:33, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> Hi luci
>>>
>>> I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.
>>>
>>> Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):
>>>
>>> Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.
>>>
>>> It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.
>>>
>>> I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.
>>>
>>> Brendan
>>>
>>>
>>>
>>>> On May 19, 2017, at 5:28 AM, luciash <[hidden email]> wrote:
>>>>
>>>> Hi Brendan,
>>>>
>>>> thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.
>>>>
>>>> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>>>>
>>>> Just my 2c.
>>>>
>>>> luci
>>>>
>>>> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>>>>
>>>>
>>>>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>>>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>>>>
>>>>> Its mostly just a straightforward port, but there are a few differences.
>>>>>
>>>>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>>>>
>>>>> A few other minor changes including:
>>>>> Better error checking
>>>>> Better error reporting
>>>>> Better archive compression
>>>>> .tar.gz and .tar.bz2 now preserve file permissions
>>>>> Stripping of .gitignore (and similar files) was extended
>>>>> OSX tested and ready
>>>>>
>>>>> Anyone who would like to test please do. Be sure to run with —no-commit option :)
>>>>>
>>>>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>>>>
>>>>> Brendan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites,
>>>>> Slashdot.org! http://sdm.link/slashdot
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TikiWiki-devel mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] release.php

luciash d' being
In reply to this post by Brendan Ferguson

Thank you for your lengthy explanation. It makes sense now to me and looks good.

luci


On 19.5.2017 15:33, Brendan Ferguson wrote:
Hi luci

I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.

Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):

Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.

It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.

I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow. 

Brendan



On May 19, 2017, at 5:28 AM, luciash <[hidden email]> wrote:

Hi Brendan,

thanks for your hard work! Well done! I have just a little objection about the "The release process now makes a export of the working copy" change.

It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?

Just my 2c.

luci

PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.



On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.

Its mostly just a straightforward port, but there are a few differences.

The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.

A few other minor changes including:
Better error checking
Better error reporting
Better archive compression
.tar.gz and .tar.bz2 now preserve file permissions
Stripping of .gitignore (and similar files) was extended
OSX tested and ready

Anyone who would like to test please do. Be sure to run with —no-commit option :)

Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?

Brendan





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Loading...