You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/04/09 04:20:57 UTC
[GitHub] [incubator-nuttx] btashton opened a new pull request #757: Create
release artifacts for release branches
btashton opened a new pull request #757: Create release artifacts for release branches
URL: https://github.com/apache/incubator-nuttx/pull/757
This extends the CI system to generate release bundles for the pushes to the `releases/<ver>` branch.
Right now we have the release branch as something like nuttx-0.9 I would highly recommend moving to the `releases/` structure as it is much easier to script around. This also pulls the coresponding branch on apps so it needs to be created there as well.
You can see an example of the run here against `release/0.9` fake branch I created including the resulting artifact.
https://github.com/btashton/incubator-nuttx/actions/runs/74119132
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-nuttx] Ouss4 commented on issue #757: Create release
artifacts for release branches
Posted by GitBox <gi...@apache.org>.
Ouss4 commented on issue #757: Create release artifacts for release branches
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-611545263
@btashton How do we proceed with signing the tarballs?
The signing and hashing are both conditioned with the -s option. Maybe we create the hashes unconditionally and test them before signing?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release
artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757: Create release artifacts for release branches
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-611592658
I don't really have a strong opinion on this bit. Generating the hashes seems harmless.
With this I just want to get as close to a release flow as possible so it is easier to check.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-nuttx] btashton commented on pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-621640317
I'm going to close this out. We can revisit it later if we want.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411888648
##########
File path: tools/README.txt
##########
@@ -1137,3 +1137,22 @@ zipme.sh
Same as above but use the key-id XXXXXX to sign the tarballs
./tools/zipme.sh -e "*.swp tmp" 9.0.0
Create the tarballs but exclude any .swp file and the "tmp" directory.
+
+gitver.sh
Review comment:
version.sh has the similar logic to generate version from tag:
```
if [ -z ${VERSION} ] ; then
VERSION=`git tag --sort=taggerdate | tail -1 | cut -d'-' -f2`
# Earlier tags used the format "major.minor", append a "0" for a patch.
if [[ ${VERSION} =~ ^([0-9]+[\.][0-9]+)$ ]] ; then
VERSION=${VERSION}.0
fi
fi
```
If the current method isn't good, it's better to replace with your new appraoch there.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411868768
##########
File path: tools/README.txt
##########
@@ -1137,3 +1137,22 @@ zipme.sh
Same as above but use the key-id XXXXXX to sign the tarballs
./tools/zipme.sh -e "*.swp tmp" 9.0.0
Create the tarballs but exclude any .swp file and the "tmp" directory.
+
+gitver.sh
Review comment:
This computes the version in an importantly different way since it take a minimum version and uses tag information to find a suitable version string.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617093661
> Unfortunately we have to create the tarballs and then sign and upload them to the Apache server staging area then provide that link in the email to vote.
>
Yes, the signing is hard to automation since nobody want to expose his/her private key publicly, the release manager need to sign the package and send email manually.
> Also creating the tarballs on the push event means we actually get what made it into the branch instead of the PR. The way I have it wired up here also means that we insure that the tag in the apps and the tag in the os are properly built against each other which would be harder to do if we are doing it off the PR.
>
I notice both apps and nuttx package is generated from the nuttx repo. Is it better that:
1.The change for nuttx release branch extract the nuttx package
2.The change for apps release branch extract the apps package
I am afraid that the apps package is incorrect if the release manager forget merge apps release branch first.
For apps/nuttx synchronization issue, I suppose the patches which enter into the release branch should seldomly couple between apps and nuttx.
> I had spent a few hours trying to work on the CI system to automate creating the backports via labels but ran into some limitations around GitHub Actions in the context of pull requests.
Since patches get cherry-picked into release branch is very important to track the change history, I still think that one PR which contain all critical fix is better than the automation backport. Since the number of patch need to backport should be small, the automation isn't very important here.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616964963
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
The version string is just used here:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
```
I think the below variant should also work too:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
```
If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
1.User confuse which script he/she should to use
2.Developer may forget to update both script at the same time
If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616964963
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
Run version.sh without
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
The version string is just used here:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
```
I think the below variant should also work too:
VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
1.It confuse user which script he/she should use
2.Developer may forget to update both script at the same time
If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617042976
> > This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
>
> This ci is the best place: we can automatically increase the release tag before zipme.sh is executed.
This runs on every commit pushed to the release branch. We do not have tags on all of these this is why we need the extra logic not simply a look up of the tag. I'm saying my script actually is missing something here which is to detect if it should be incrementing the patch number because we have a commit ahead of the last release tag.
Once 0.1.2 is tagged the next builds in the branch should start being 0.1.3 until 0.1.3 is tagged and released.
As for not having RC builds, I don't know. Most of the projects I have worked on do them. I thought we were going to go then here as well, but it does not really change anything.
I really just wanted this so we have the tarballs generated for testing and to be able to upload the 9.0.0 release candidate when we agree.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616970850
> The version string is just used here:
>
> ```
> VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
> ```
>
> I think the below variant should also work too:
>
> ```
> VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
> ```
The additional matches are intentional. I watch to match
```
nuttx-0.1
nuttx-0.1.1 nuttx-0.1.2 nuttx-0.1.3
nuttx-0.1.1-RC1
```
I do _not_ want to match `nuttx-some-fix` and more importantly at some point we will tag
9.1 and may still backport and only want to match 9.0.# not 9.1.#
>
> If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
> It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
> 1.It confuse user which script he/she should use
> 2.Developer may forget to update both script at the same time
> If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
`version.sh` is expecting to be passed a full version string `gitversion.sh` can provide this value to it in the context of a CI run. It really does not make sense outside of a CI run, but it is complicated enough I did not want to shove it in the yaml file.
```
$ version.sh -v `gitversion.sh 0.1`
```
`version.sh` job is really just setting the config files. The fact that it tries to guess a version number from git is out of its job in my opinion. Why not drop version being optional and just:
```
version.sh -v `git describe --match nuttx-[0-9].* --abbrev=0`
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616998054
I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC`
2. If a tag is found already with the major and minor then we use the latest patch field.
3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616946711
How about we make zipme.sh major.minor.patch optional:
https://github.com/apache/incubator-nuttx/pull/834
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617078413
Unfortunately we have to create the tarballs and then sign and upload them to the Apache server staging area then provide that link in the email to vote.
Also creating the tarballs on the push event means we actually get what made it into the branch instead of the PR. The way I have it wired up here also means that we insure that the tag in the apps and the tag in the os are properly built against each other which would be harder to do if we are doing it off the PR.
I had spent a few hours trying to work on the CI system to automate creating the backports via labels but ran into some limitations around GitHub Actions in the context of pull requests.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616964963
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
The version string is just used here:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
```
I think the below variant should also work too:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
```
If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
1.It confuse user which script he/she should use
2.Developer may forget to update both script at the same time
If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411868216
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
This is only for release branches.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616964963
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
> > How about we make zipme.sh major.minor.patch optional:
> > #834
>
> It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
The version string is just used here:
```
VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
```
I think the below variant should also work too:
VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
1.It confuse user which script he/she should use
2.Developer may forget to update both script at the same time
If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617031731
> I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
>
> We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
>
> 1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC`
BTW, can we drop {major}.{minor}.{patch}-RC? it's hard to handle uniformly with other tags? we can start from {major}.{minor}.0 and increase the last number one by one after we fix the critical issue reported by user. The {major}.{minor},{largest} is always the best release for {major}.{minor}.
> 2. If a tag is found already with the major and minor then we use the latest patch field.
> 3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
BTW, should we always create {major}.{minor}.0 tag for the first preview release? Otherwise we may miss the release tag if no any issue is reported during the public test phase.
>
> Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
>
> For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
>
Yes, this is the real difference between gitver.sh and version.sh:
1.version.sh want to get the latest tag name
2.gitver.sh want to get the latest tag name for a particular release
But, it's easy to detect which case the script is running in:
```
if branch-name start with "release/[0-9].[0-9]"
git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION"...
else
git describe --abbrev=0
fi
```
> This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
>
Yes, but it will reduce the maintain cost if the effort isn't too huge to improve the current tool for the new case. Otherwise, we have to change more place if we want to change the release schema in futrure.
> This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
This ci is the best place: we can automatically increase the release tag before zipme.sh is executed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411837618
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
Could we change name to Package? since other
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616998054
I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC
2. If a tag is found already with the major and minor then we use the latest patch field.
3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617031731
> I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
>
> We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
>
> 1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC`
BTW, can we drop {major}.{minor}.{patch}-RC? it's hard to handle uniformly with other tags? we can start from {major}.{minor}.0 and increase the last number one by one after we fix the critical issue reported by user. The {major}.{minor},{largest} is always the
> 2. If a tag is found already with the major and minor then we use the latest patch field.
> 3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
BTW, should we always create {major}.{minor}.0 tag for the first preview release? Otherwise we may miss the release tag if no any issue is reported during the public test phase.
>
> Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
>
> For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
>
Yes, this is the real difference between gitver.sh and version.sh:
1.version.sh want to get the latest tag name
2.gitver.sh want to get the latest tag name for a particular release
But, it's easy to detect which case the script is running in:
```
if branch-name start with "release/[0-9].[0-9]"
git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION"...
else
git describe --abbrev=0
fi
```
> This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
>
Yes, but it will reduce the maintain cost if the effort isn't too huge to improve the current tool for the new case. Otherwise, we have to change more place if we want to change the release schema in futrure.
> This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
this ci is the best place: we can automatically increase the release tag before zipme.sh is executed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617097395
> > Also creating the tarballs on the push event means we actually get what made it into the branch instead of the PR. The way I have it wired up here also means that we insure that the tag in the apps and the tag in the os are properly built against each other which would be harder to do if we are doing it off the PR.
> >
>
> I notice both apps and nuttx package is generated from the nuttx repo. Is it better that:
> 1.The change for nuttx release branch extract the nuttx package
> 2.The change for apps release branch extract the apps package
> I am afraid that the apps package is incorrect if the release manager forget merge apps release branch first.
> For apps/nuttx synchronization issue, I suppose the patches which enter into the release branch should seldomly couple between apps and nuttx.
>
The way this is setup right now on non tagged commits it will pick the latest from the the corresponding branch in app.
But importantly if there is a tag it will build that and fail if it cannot find that same tag in the app. So we know exactly what was built and we have the set of tarballs and signatures from it.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411835163
##########
File path: tools/gitver.sh
##########
@@ -0,0 +1,69 @@
+#!/bin/bash
+
+#****************************************************************************
+# tools/gitversion.sh
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership. The
+# ASF licenses this file to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance with the
+# License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+#****************************************************************************
+
+# This script will attempt to generate a semver version based on the git tags
+# and the supplied target version as either major.minor or major.minor.patch
+# If there is not yet a tag for Version 0.1 and 0.1 is supplied it will
+# return the version 0.1.0 If a tag exists of 0.1.2-RC1 it would return
+# version 0.1.2 to standard out if 0.1 or 0.1.2 is supplied
+#
+# Example usage:
+# $ ./gitver.sh 0.1
+# 0.1.2
Review comment:
@Ouss4 Done. If we add this to the release branch I think we will start generating the release tarballs.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617031731
> I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
>
> We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
>
> 1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC`
BTW, can we drop {major}.{minor}.{patch}-RC? it's hard to handle uniformly with other tags? we can start from {major}.{minor}.0 and increase the last number one by one after we fix the critical issue reported by user. The {major}.{minor},{largest} is always the best release for {major}.{minor}.
> 2. If a tag is found already with the major and minor then we use the latest patch field.
> 3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
BTW, should we always create {major}.{minor}.0 tag for the first preview release? Otherwise we may miss the release tag if no any issue is reported during the public test phase.
>
> Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
>
> For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
>
Yes, this is the real difference between gitver.sh and version.sh:
1.version.sh want to get the latest tag name
2.gitver.sh want to get the latest tag name for a particular release
But, it's easy to detect which case the script is running in:
```
if branch-name start with "release/[0-9].[0-9]"
git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION"...
else
git describe --abbrev=0
fi
```
> This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
>
Yes, but it will reduce the maintain cost if the effort isn't too huge to improve the current tool for the new case. Otherwise, we have to change more place if we want to change the release schema in futrure.
> This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
this ci is the best place: we can automatically increase the release tag before zipme.sh is executed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617056220
> > > This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}`
> >
> >
> > This ci is the best place: we can automatically increase the release tag before zipme.sh is executed.
>
> This runs on every commit pushed to the release branch. We do not have tags on all of these this is why we need the extra logic not simply a look up of the tag. I'm saying my script actually is missing something here which is to detect if it should be incrementing the patch number because we have a commit ahead of the last release tag.
Can we make package.yaml is triggered by PR not by an indvidual commit just like check.yaml/build.yaml? Then we can prepare the new release PR by cherry-pick all critical bugfix from master during public preview and merge all commit in one click. The process may as the follow:
1.Collect all bugfix in a new PR against release/x.x branch
2.Pass all check/build/test(in the furture)
3.Send the vote email with the PR link
4.Run package.yaml when PR merge to release
a.Increase the patch number automatically
b.Call zipme.sh to generate the package zip
5.Announce the new release candidate with the download link
Repeat step 1 to 5 if some critical bug found during the preview phase, otherwise the release candidate become the offical release and upload to Apache server.
> Once 0.1.2 is tagged the next builds in the branch should start being 0.1.3 until 0.1.3 is tagged and released.
>
> As for not having RC builds, I don't know. Most of the projects I have worked on do them. I thought we were going to go then here as well, but it does not really change anything.
>
> I really just wanted this so we have the tarballs generated for testing and to be able to upload the 9.0.0 release candidate when we agree.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411888648
##########
File path: tools/README.txt
##########
@@ -1137,3 +1137,22 @@ zipme.sh
Same as above but use the key-id XXXXXX to sign the tarballs
./tools/zipme.sh -e "*.swp tmp" 9.0.0
Create the tarballs but exclude any .swp file and the "tmp" directory.
+
+gitver.sh
Review comment:
version.sh has the similar logic to generate version from tag, if the current method isn't good, it's better to replace with your new appraoch there.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616952031
> How about we make zipme.sh major.minor.patch optional:
> #834
It is not clear to me how that would help. We want to supply the version string, we just want to compute it differently.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616998054
I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC
2. If a tag is found already with the major and minor then we use the latest patch field.
3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.{patch}`
Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411837618
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
Could we change name to Package? since other
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
Could we change name to Package just like other action style(e.g. Check/Build/Doc)?
##########
File path: tools/gitver.sh
##########
@@ -0,0 +1,63 @@
+#!/bin/bash
+
+#****************************************************************************
+# tools/gitversion.sh
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership. The
+# ASF licenses this file to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance with the
+# License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+#****************************************************************************
+
+# Example usage:
+# $ ./gitver.sh 0.1
+# 0.1.2
+
+if [ $# -ne 1 ]
+then
+ echo "Missing version argument" 1>&2
+ exit -1
+fi
+
+NUTTX_VERSION=$1
+
+# Closest Tag of this Version
+VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
+if [ $? -ne 0 ]
+then
+ VER_TAG=nuttx-$NUTTX_VERSION
+fi
+
+
+# Remove nuttx and possible RC
+VER_TAG=`echo $VER_TAG | cut -d'-' --fields=2`
+
+# If version does not have a patch add one
+if [ `expr match $VER_TAG '.'` -eq 1 ]
+then
+ VER_TAG=${VER_TAG}.0
+fi
+
+SEMVER_REGEX="([0-9]+).([0-9]+).([0-9]+)"
+if [[ $VER_TAG =~ $SEMVER_REGEX ]]
+then
+ major="${BASH_REMATCH[1]}"
+ minor="${BASH_REMATCH[2]}"
+ patch="${BASH_REMATCH[3]}"
+else
+ echo "Unexpected Version format: $VER_TAG" 1>&2
+ exit -1
+fi
+
+echo ${major}.${minor}.${patch}
Review comment:
Add a new line to remvoe the tail read mark?
##########
File path: tools/README.txt
##########
@@ -1137,3 +1137,22 @@ zipme.sh
Same as above but use the key-id XXXXXX to sign the tarballs
./tools/zipme.sh -e "*.swp tmp" 9.0.0
Create the tarballs but exclude any .swp file and the "tmp" directory.
+
+gitver.sh
+---------
+
+ This script will attempt to generate a semver version based on the git tags
+ and the supplied target version as either major.minor or major.minor.patch
+ If there is not yet a tag for Version 0.1 and 0.1 is supplied it will
+ return the version 0.1.0 If a tag exists of 0.1.2-RC1 it would return
+ version 0.1.2 to standard out if 0.1 or 0.1.2 is supplied.
+
+ This is helpful for generating a version string for a release tarbal on a
Review comment:
tarbal to tarball
##########
File path: tools/gitver.sh
##########
@@ -0,0 +1,63 @@
+#!/bin/bash
+
+#****************************************************************************
+# tools/gitversion.sh
Review comment:
gitver.sh
##########
File path: tools/README.txt
##########
@@ -1137,3 +1137,22 @@ zipme.sh
Same as above but use the key-id XXXXXX to sign the tarballs
./tools/zipme.sh -e "*.swp tmp" 9.0.0
Create the tarballs but exclude any .swp file and the "tmp" directory.
+
+gitver.sh
Review comment:
It seem that version.sh can generate the similar version info like gitver.sh, can we reuse version.sh?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] Ouss4 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
Ouss4 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617141583
> I notice both apps and nuttx package is generated from the nuttx repo. Is it better that:
1.The change for nuttx release branch extract the nuttx package
2.The change for apps release branch extract the apps package
I am afraid that the apps package is incorrect if the release manager forget merge apps release branch first.
We can automate this part in the zipme.sh script and also check if the script is called from a release branch and not master or any other development branch.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616986400
> I do _not_ want to match `nuttx-some-fix` and more importantly at some point we will tag
> 9.1 and may still backport and only want to match 9.0.# not 9.1.#
>
We can get this information by:
```
git branch --show-current
```
> `version.sh` is expecting to be passed a full version string `gitversion.sh` can provide this value to it in the context of a CI run. It really does not make sense outside of a CI run, but it is complicated enough I did not want to shove it in the yaml file.
>
No, version.sh is also used when the user who clone git directly. In this case, .version is automatically generated in the build process by version.sh. We must ensure that the generated version number is same regardless which method user is used to get the package.
> ```
> $ version.sh -v `gitversion.sh 0.1`
> ```
>
> `version.sh` job is really just setting the config files. The fact that it tries to guess a version number from git is out of its job in my opinion. Why not drop version being optional and just:
>
> ```
> version.sh -v `git describe --match nuttx-[0-9].* --abbrev=0`
> ```
As I note before, we need consider the user who use repo directly and merge the upstream regularly after each major release. version.sh is only method here.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411870416
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
Renamed it to be more specific.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton edited a comment on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton edited a comment on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616998054
I think we are not talking about the same thing here, so let me write the problem I am trying to solve.
We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this
1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC
2. If a tag is found already with the major and minor then we use the latest patch field.
3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0`
Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools.
For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much).
This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#discussion_r411887192
##########
File path: .github/workflows/package.yml
##########
@@ -0,0 +1,58 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+name: Release CI (package)
Review comment:
How about Package(release)?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on issue #757: Create release artifacts for release branches
Posted by GitBox <gi...@apache.org>.
btashton commented on issue #757:
URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-616970850
> The version string is just used here:
>
> ```
> VER_TAG=`git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION" --match "nuttx-$NUTTX_VERSION-*" --match "nuttx-$NUTTX_VERSION.[0-9]*" 2>/dev/null`
> ```
>
> I think the below variant should also work too:
>
> ```
> VER_TAG=`git describe --abbrev=0 --match "nuttx-*" 2>/dev/null`
> ```
The additional matches are intentional. I watch to match
```
nuttx-0.1
nuttx-0.1.1 nuttx-0.1.2 nuttx-0.1.3
nuttx-0.1.1-RC1
```
I do _not_ want to match `nuttx-some-fix`
>
> If not, we still can pass BRANCH_VER=${GITHUB_REF##*/} to zipme.sh and then version.sh.
> It doesn't make sense that we have two scripts(version.sh and gitver.sh) generate the similar thing, because:
> 1.It confuse user which script he/she should use
> 2.Developer may forget to update both script at the same time
> If version.sh doesn't work well with release process, it's better to enhance it to handle the new usage correctly instead creating a new similar script.
`version.sh` is expecting to be passed a full version string `gitversion.sh` can provide this value to it in the context of a CI run. It really does not make sense outside of a CI run, but it is complicated enough I did not want to shove it in the yaml file.
```
$ version.sh -v `gitversion.sh 0.1`
```
`version.sh` job is really just setting the config files. The fact that it tries to guess a version number from git is out of its job in my opinion. Why not drop version being optional and just:
```
version.sh -v `git describe --match nuttx-[0-9].* --abbrev=0`
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org