GSoC 2020 : App Store phase 1 review request and weekly report.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC 2020 : App Store phase 1 review request and weekly report.

shivamani patil
Hello everyone,

*Work done previous week:*
- Completed bash scripts used in Jenkins pipelines. There are 4 bash
scripts for each use case.

*Phase-1 Review Request:*
I have completed the deliverables planned for the Phase-1 of the GSoC
Project.

I added the Build model to the App Store which will be used to store the
build info for a  module/fork release. The main component during this phase
was to come up with the parametrized pipeline workflows for each case of
module/fork with and without bakefile cases. Doc explaining the workflow
and scripts used in pipelines can be found here [1].
Merge request related to work done in phase 1 can be found here [2].
Currently, developers should follow some guidelines if they wish to use the
Jenkins server for receiving the build status of their releases [3].

*Outcomes: *Scripts that will be used by Jenkins pipelines are complete and
pipeline workflows are decided.

Any feedback or suggestions on the work would be much appreciated.

[1]
https://docs.google.com/document/d/1ekx4xlLK6KDj9TnFTpxVFp_7RelAYe7JvzX-Y5RRfhA/edit?usp=sharing
[2] https://gitlab.com/nsnam/ns-3-AppStore/-/merge_requests/69
[3]
https://docs.google.com/document/d/19xdtI-qfJmVoJJK-JN88jyNBQAyrkBvfuM_nTfdSh_s/edit?usp=sharing

Regards,
Shivamani Patil
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 : App Store phase 1 review request and weekly report.

Tom Henderson-2
On 6/29/20 5:40 AM, shivamani patil wrote:

> Hello everyone,
>
> *Work done previous week:*
> - Completed bash scripts used in Jenkins pipelines. There are 4 bash
> scripts for each use case.
>
> *Phase-1 Review Request:*
> I have completed the deliverables planned for the Phase-1 of the GSoC
> Project.
>
> I added the Build model to the App Store which will be used to store the
> build info for a  module/fork release. The main component during this phase
> was to come up with the parametrized pipeline workflows for each case of
> module/fork with and without bakefile cases. Doc explaining the workflow
> and scripts used in pipelines can be found here [1].
> Merge request related to work done in phase 1 can be found here [2].
> Currently, developers should follow some guidelines if they wish to use the
> Jenkins server for receiving the build status of their releases [3].
>
> *Outcomes: *Scripts that will be used by Jenkins pipelines are complete and
> pipeline workflows are decided.
>
> Any feedback or suggestions on the work would be much appreciated.
>
> [1]
> https://docs.google.com/document/d/1ekx4xlLK6KDj9TnFTpxVFp_7RelAYe7JvzX-Y5RRfhA/edit?usp=sharing
> [2] https://gitlab.com/nsnam/ns-3-AppStore/-/merge_requests/69
> [3]
> https://docs.google.com/document/d/19xdtI-qfJmVoJJK-JN88jyNBQAyrkBvfuM_nTfdSh_s/edit?usp=sharing
>
> Regards,
> Shivamani Patil
>

Hi Shivamani, can you summarize a bit more and answer a few questions?

- is there a publicly visible Jenkins server anywhere that is making use
of your phase 1 work?  If not, do you need access to one?

- in the eventual system, what will be the triggers to try to rebuild an
app with the compatible ns-3?  App source code changes, or ns-3-dev code
changes, or periodic scheduled builds?

- regarding the request to have apps following the guidelines for how to
publish releases, it seems that you are steering people away from
publishing release tarballs and asking them to use git tags and
branches.  What is the issue with supporting both methods?  Is it just
that apps that have not published a bakeconf.xml are not providing the
necessary metadata about the nature of the release download link?

- did you encounter any issues with completing phase 1 that blocked your
goals in any way?

Thanks,
Tom
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 : App Store phase 1 review request and weekly report.

shivamani patil
On Wed, Jul 1, 2020 at 3:56 AM Tom Henderson <[hidden email]> wrote:

> Hi Shivamani, can you summarize a bit more and answer a few questions?
>
> - is there a publicly visible Jenkins server anywhere that is making use
> of your phase 1 work?  If not, do you need access to one?

Currently, the REST API's code for fetching the bakefiles(GSoC 19) is not
deployed to https://apps.nsnam.org so in my local pipelines, I am cloning
forked Bake with AppStore URL changed to the localhost App Store. So
publicly Jenkins server (if deployed) won't be able to fetch bakefiles as
that App Store code is yet to be deployed.

>
> - in the eventual system, what will be the triggers to try to rebuild an
> app with the compatible ns-3?  App source code changes, or ns-3-dev code
> changes, or periodic scheduled builds?
>
 We have releases for each app in the App Store and they specify a specific
ns-3 version for each such release. And if they change the App source Code
most likely they will add a new release (and maybe new ns-3 version for
that release) in the App Store for that app. So currently, I am thinking of
adding rebuild triggers as build buttons for admins or maybe to the
developers in the admin panel and on the releases section of apps.
Regarding code change triggers - I think only those app releases who
specified ns-3-dev as required ns-3 version should rebuild after new
commits are added to that repo(can be done using gitlab webhooks) as other
specific ns-3 release code won't change. Also, I was thinking of scheduling
periodic builds for app releases. Exact scripts and workflows for this App
Store side of triggering build is phase 2 of my project.

>
> - regarding the request to have apps following the guidelines for how to
> publish releases, it seems that you are steering people away from
> publishing release tarballs and asking them to use git tags and
> branches.  What is the issue with supporting both methods?  Is it just
> that apps that have not published a bakeconf.xml are not providing the
> necessary metadata about the nature of the release download link?
>
I am not preferring one method to the other. Currently, both methods can be
supported i.e
1) Direct tarball download link 2) link to the repo with some info about
the release(tag name of the release, or maybe even branch).
For a direct download link, I said that they should extract to one parent
folder as they can give nested directories then it is hard to know where
the actual app code resides.
And for git repo link option, I saw app releases on App Store giving
different links e.g (one pointing to /releases, some to tree/<tag-name>) so
as these different links are given it can be difficult to fetch the actual
app code. So I was just suggesting a guideline as they can give repo link
in format github/gitlab.com/<username>/<repo-name> and version option can
be given as release-tag or even branch name. This way it becomes easy to
fetch the single branch/tag code from that repo. Anyway, currently, there
are app releases with different URL structures(for repo links), therefore I
am planning on formating these URL's before triggering the build from App
Store. I discussed this with mentors they said currently these restrictions
or limitations are fine, maybe we can support more types in the future.

- did you encounter any issues with completing phase 1 that blocked your
> goals in any way?
>
Issues I faced while completing phase 1 are mostly related to naming issues
or structuring issues e.g bakefile names, module names, repo links, for
this maybe we could write some guidelines regarding these things. Also, the
bakefile code which I will be using is not yet deployed for App Store but
is pushed onto the App Store repo.

>
> Thanks,
> Tom
>

Regards,
Shivamani Patil